[Qgis-developer] Re: QGis & Python
Echavarria Gregory, Maria Angelica
m.echavarriagregory at umiami.edu
Mon Nov 30 11:10:39 EST 2009
Pierre,
I had trouble with my installation too with the same simptoms you talk about. My solution was quite unconventional and may be attacked :-| but it worked:
- Install the OSGeo4W 1.0 Kore (the Mimas unfortunately did not work for me). Until here, it will complain about the DLLs...
- Go to /OSGeo4W/apps/qgis/bin where you will find the qgis.core and qgis.gui DLLs. Copy them. Do not delete them.
- Paste the DLLs to OSGeo4W/apps/qgis/python/qgis folder... taraaaan, it should work now.
- Work from the OSGeo4W console, not from your previous python installation..
- Then you can add the PYTHONPATH, PATH and QGIS Home to your environment variables as German Carrillo said using the bat file or by hand in your Mac or Windows control panel under "system", "advanced" option... Note that if you dont add the variables, you would need to append the entire paths to your sys.path every time you open a python console..., like this:
sys.path.append("C:/OSGeo4W/apps/qgis")
sys.path.append("C:/OSGeo4W/apps/qgis/python")
sys.path.append("C:/OSGeo4W/apps/qgis/python/qgis")
Angelica.
M. Angelica Echavarria-Gregory,
Ph.D Candidate
________________________________________
From: qgis-developer-bounces at lists.osgeo.org [qgis-developer-bounces at lists.osgeo.org] On Behalf Of qgis-developer-request at lists.osgeo.org [qgis-developer-request at lists.osgeo.org]
Sent: Monday, November 30, 2009 10:36 AM
To: qgis-developer at lists.osgeo.org
Subject: Qgis-developer Digest, Vol 45, Issue 63
Send Qgis-developer mailing list submissions to
qgis-developer at lists.osgeo.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/qgis-developer
or, via email, send a message with subject or body 'help' to
qgis-developer-request at lists.osgeo.org
You can reach the person managing the list at
qgis-developer-owner at lists.osgeo.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Qgis-developer digest..."
Today's Topics:
1. Re: [Graphics] Re: new gis theme and common repository
(Steven M. Ottens)
2. Re: Create groups in python plugins (Andres Manz)
3. Re: Create groups in python plugins (Martin Dobias)
4. Fwd: [Qgis-developer] Create groups in python plugins
(Andres Manz)
5. Re: segfault python: no catch for QgsException? (Martin Dobias)
6. Re: QGis & Python (Germ?n Carrillo)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Nov 2009 12:19:58 +0100
From: "Steven M. Ottens" <steven at minst.net>
Subject: [Qgis-developer] Re: [Graphics] Re: new gis theme and common
repository
To: Robert Szczepanek <robert at szczepanek.pl>
Cc: "qgis-developer at lists.osgeo.org" <qgis-developer at lists.osgeo.org>,
Anita Graser <anitagraser at gmx.at>, graphics at lists.osgeo.org
Message-ID: <72F09AD8-5472-46BC-9244-09D2E757DB5D at minst.net>
Content-Type: text/plain; charset=us-ascii
Hi all,
On Nov 30, 2009, at 9:28 AM, Robert Szczepanek wrote:
> Hi Anita,
>
> Thank you for this e-mail. You pointed important issues.
>
> Anita Graser pisze:
>> Hi all,
>>
>> Great that we have a working SVN now. How will we continue from this point?
>
> In fact it's up to us. Tango approach is for me good example.
I agree, they have a well thought out approach with documentation on how to implement it. [1]
> First discussion (mailing list, chat, whatever) - then work. Otherwise
> we loose time and wishes correcting our/others work.
> So we do not focus on duplicating work (many themes), but on covering
> different target users of graphics (16x16px, 32x32px, svg, etc).
I believe the SVN set should be a reference implementation for GIS related icons/gfx. We should focus on creating a complete set in all resolutions. If applications want to create there own theme, it is up to them.
> But to do that, we must first agree on basic metaphores. Next step can
> be discussion on their details.
> Good example can be discussion on OGC services
> http://lists.osgeo.org/pipermail/graphics/2009-November/000028.html
We need to create a list of all needed icons and their metaphors, similar to the tange page [2]
The list on the wiki [3]: is a good starting point. I suggest to start with defining a basic iconset (for instance without the advanced GIS functionality from GRASS). Discuss metaphors and once an agreement is reached put the metaphor behind the icon-name.
Finally once icons are pouring in we can show them in the same table, having columns for 16x16, 22x22, 32x32 and scalable so one can see at once if that icon is available.
> This for sure takes longer, but we do it once.
> Once ... per version :)
Indeed.
>
> An alternative can be collection of different themes in one place, but
> in my opinion this will be impossible to manage in a while.
> Link to
> source themes in graphics wiki is enough. Just my opinion.
+1
>
>> Will we upload only the .SVG files there ore also .PNGs?
>
> I would collect source svg and renders in different sizes. As you know
> it is impossible to render from one svg icons in 16x16px and 64x64px and
> not all graphic users (developers) want to play with svg. We need to
> define target png sizes and name svg layers accordingly.
> So if our svg layer is for 16x16 and 32x32 we call it 16-32.
> This way it will be easy to use such svg later for automatic (batch?)
> processing.
> Question is HOW to organise folders structure and file names.
> Sub-folders for every size or for example
> core-name.svg
> core-name_16.png
> core-name_32.png...
> Developers comments are welcome.
Tango uses in its releases:
16x16/actions/address-book-new.png
22x22/actions/address-book-new.png
32x32/actions/address-book-new.png
scalable/actions/addrress-book-new.svg
In their repository they use:
16x16/actions/address-book-new.png
16x16/actions/address-book-new.xcf.bz2 <- source file, can be .svg as well
22x22/actions/address-book-new.png
22x22/actions/address-book-new.xcf.bz2
32x32/actions/address-book-new.png
32x32/actions/address-book-new.svg
scalable/actions/address-book-new.svg
They have an autogen setup which apparently renders all icons in 24x24 as well (adding a 1px border to 22x22 icons)
I believe they chose this file structure to comply with the freedesktop.org icon theme specification [4] I'm not sure how relevant this is for our purpose. It would be nice to come up with a standard file-structure so applications developers can either adept their structure to it, or write a translation script to change the structure to the one that fits their application.
>
> Do we agree on
>> changing the color palette to Tango?
>
> Yes.
+1
>
> Is the wiki page the main reference
>> for which icons exist and which are planned?
>
> Wiki as reference for existing icons - yes. In my understanding wiki is
> good place for describing meaning and use scope of icons. And pictures
> from trunk. For planned (or to change) ones better place is trac system.
> I have no experience in this field, so please correct me if I'm wrong.
As I wrote before I think having one wikipage with an overview is the way to go. We can add links to trac-issues on planned/to-be-changed icons. This way someone can claim an icon in trac and preventing double work.
>
> Or is there some other
>> place? Will we discuss all icons on the mailing list or should we change
>> to the wiki discussion page, where we can easily link pictures to our
>> comments?
>>
>> Best wishes,
>> Anita
>
> I would prefer mailing list for discussion at the moment, but if there
> are arguments for wiki discussion, we can do it other way.
I'd say we discuss here (and in chat if needed) and write down conclusions on the wiki for future reference
Steven
[1] http://tango.freedesktop.org/Generic_Icon_Theme_Guidelines
[2] http://tango.freedesktop.org/Icon_Metaphors
[3] http://wiki.osgeo.org/wiki/OSGeo_Graphics#Application_icons
[4] http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
------------------------------
Message: 2
Date: Mon, 30 Nov 2009 12:39:07 +0100
From: Andres Manz <manz.andres at gmail.com>
Subject: Re: [Qgis-developer] Create groups in python plugins
To: Martin Dobias <wonder.sk at gmail.com>
Cc: qgis-developer at lists.osgeo.org
Message-ID:
<d74603e80911300339n53810fe5h9a0ab0273ad69895 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi List,
Well, I created a QgsLegendInterface with the functions
- addGroup( QString name );
- moveLayer( QgsMapLayer * layer, QString group )
- removeGroup( QString name );
There's (at least) one thing I don't like about this:
What if the user has more than one group with the same name?
All groups with the same name would be removed (removeGroup) or a
layer would be moved to the first group with the given name
(moveLayer). So the scripter / user does not have much control on the
group selection.
So if my current approach doesn't adequate, I'd prefer to create a
mini-interface for QgsLegendGroup and add it to the API, too, so the
python scripter would have a handle for the groups. (I would not know
how to name it, as a QgsLegendGroup already exists and QgsGroup would
be a bit too general, I guess. ;-))
Any objections?
I'm a little bit in a hurry, so I'm sorry it takes so long. Patch will
follow soon.
Regards
Andres
------------------------------
Message: 3
Date: Mon, 30 Nov 2009 13:03:44 +0100
From: Martin Dobias <wonder.sk at gmail.com>
Subject: Re: [Qgis-developer] Create groups in python plugins
To: Andres Manz <manz.andres at gmail.com>
Cc: qgis-developer at lists.osgeo.org
Message-ID:
<e8e7199c0911300403t5a97386dx7f31af76b0aa3433 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Nov 30, 2009 at 12:39 PM, Andres Manz <manz.andres at gmail.com> wrote:
> Hi List,
>
> Well, I created a QgsLegendInterface with the functions
> - addGroup( QString name );
> - moveLayer( QgsMapLayer * layer, QString group )
> - removeGroup( QString name );
>
> There's (at least) one thing I don't like about this:
> What if the user has more than one group with the same name?
> All groups with the same name would be removed (removeGroup) or a
> layer would be moved to the first group with the given name
> (moveLayer). So the scripter / user does not have much control on the
> group selection.
Hi Andres
what about using indices for groups? You could create a groups()
method that would return a list of groups, the groups could be
addressed by the index instead of name, so:
int addGroup( QString name ) ... returns index of newly added group
QStringList groups()
moveLayer( ... ) ... should be enough flexible to allow ordering also
within groups, moving out of groups, maybe even moving of groups?
removeGroup ( int groupIndex ) ... one thing to consider is whether
all layers within the group should be removed too or not...
I think there's also place for additional functions for querying /
setting legend items: order of layers, layer/group visibility etc. But
I'm not sure how much time would you like to invest into that :-) Just
try to design the API to be easily extensible.
One last note - we're going to enter feature freeze very soon, so if
you want the changes to appear in 1.4 release, you should be quick :-)
Regards
Martin
------------------------------
Message: 4
Date: Mon, 30 Nov 2009 13:55:03 +0100
From: Andres Manz <manz.andres at gmail.com>
Subject: Fwd: [Qgis-developer] Create groups in python plugins
To: Martin Dobias <wonder.sk at gmail.com>
Cc: qgis-developer at lists.osgeo.org
Message-ID:
<d74603e80911300455x4f1b1c03j91f9629fa03eb465 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Martin,
At the beginning I used indices (from the QTreeWidget) instead of
strings, but there was one major problem:
When the scripter adds a group and the user moved that group, it got a
new index. But the scripter had still the old (now incorrect) index. I
could not find an intuitive way to handle that up to now. (I thought
about pointers or references for the index here.)
> moveLayer( ... ) ... should be enough flexible to allow ordering also
> within groups, moving out of groups, maybe even moving of groups?
Yes, this flexibility would be great and I thought about it, too. But
- using indices - you would have to know the index of the layer, the
group or the top element (for moving out of groups). I'll take a look
at QTreeWidget for it. It would be nice to have somthing like a
moveItem( QTreeWidgetItem * ) function, but then we would replace the
indices with QTreeWidgetItems and the scripter could do anything to
the tree.
> removeGroup ( int groupIndex ) ... one thing to consider is whether
> all layers within the group should be removed too or not...
I oriented toward legendGroupRemove() in QgsLegend, which removes the
layers, too.
> One last note - we're going to enter feature freeze very soon, so if
> you want the changes to appear in 1.4 release, you should be
> quick :-)
I don't think the additional functionality will make it into that
release, but I'll give it a try and put as much of functionality as
possible into the patch and upload it. :-)
Regards
Andres
------------------------------
Message: 5
Date: Mon, 30 Nov 2009 14:49:15 +0100
From: Martin Dobias <wonder.sk at gmail.com>
Subject: Re: [Qgis-developer] segfault python: no catch for
QgsException?
To: rdmailings at duif.net
Cc: qgis-developer List <qgis-developer at lists.osgeo.org>
Message-ID:
<e8e7199c0911300549r6ee8dcf1pb1d634f6530d9ef5 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Nov 24, 2009 at 10:50 PM, Richard Duivenvoorde
<rdmailings at duif.net> wrote:
> He Martin,
>
> Thanks for your answers,
Hi and sorry for taking it so long to get back to you...
> Martin Dobias wrote:
>>
>> what QGIS version is that? Here on svn trunk I get just a message box
>> with the error message and no crash - supposedly thanks to a last
>> resort try...catch block in QgsApplication.
>
> svn trunk ...
> doing it with r12220 or 12214, not sure which tree I used ...
> Both as a plugin and in the python console Qgis just crashes when I do
>
> from PyQt4.QtCore import *
> from PyQt4.QtGui import *
> try:
> QgsProject.instance().read(QFileInfo('/home/richard/temp/test.dbf'))
> except:
> ? ? ? ?print 'FOUT' ?# dutch for 'ERROR' :-)
>
> after I read a valid project into qgis first...
Hmm... on my comp it still shows the error message box "unable to open
..." and crashes with a segfault in python libs later when executing
any other python command - I guess due unexpected change of flow
because of the exception. On another computer it just aborts
immediately due the exception.
>> The exceptions are not recognized in Python because they're not
>> wrapped in SIP. Barry had a similar problem few months ago:
>> http://lists.osgeo.org/pipermail/qgis-developer/2009-January/005887.html
>>
>> I still think we should remove usage of exceptions from QGIS codebase
>> - either to make the API simpler and also more Qt-like. But someone
>> would have to do it :-)
>
> Removing exceptions? ... How would you handle stuff like above then (or do I
> sound very old-fashioned now ;-) ). Seriously, does Qt have an alternative
> for this?
A common pattern for handling errors without exceptions is like this:
if ( ! x.open() )
{
printf("error: %d\n", x.error();
}
instead of:
try
{
x.open();
}
catch ( exception e )
{
printf("error: %d\n", e.error());
}
This is how Qt does it too - check e.g. QFile docs.
Looking at the QgsProject class, the only methods that throw
exceptions are read() and write(). Both currently either return true
on success or end up throwing an exception. So we could remove the
usage of exceptions without a lot of fuss just by returning false on
error and adding a method to return error type (or error message).
This would be actually a tiny change in API semantics, but I think
it's worth it (considering that python plugins have trouble with
dealing the exceptions).
> If there is a good alternative, we could make it a task for people who want
> to start cpp (like me and Werner...) maybe?
Well... I can try, it might be a good excercise - depends on how much
c++ knowledge you've acquired already :-) Anyway I think I'll might
find some time during 1.4 bugfixing period to do the changes... if
there are no objections against the proposal from other devs.
Martin
------------------------------
Message: 6
Date: Mon, 30 Nov 2009 10:35:33 -0500
From: Germ?n Carrillo <carrillo.german at gmail.com>
Subject: Re: [Qgis-developer] QGis & Python
To: Pierre Cauhop? <pierre.cauhope at free.fr>,
qgis-developer at lists.osgeo.org
Message-ID:
<e32d76a10911300735w79a307b9j6a4c608579460e29 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Pierre.
On Windows I run a .bat file with this three lines:
*set PYTHONPATH=c:\qgis\python
set PATH=c:\qgis\bin;%PATH%
set PATH=c:\Python25;%PATH%*
After that I'm able to run PyQGIS applications. I use the QGIS standalone
installer.
Regards.
Germ?n.
2009/11/30 Luca Mandolesi <mandoluca at gmail.com>
>
> Sorry, but I'm working under mac os x, and the sys.path method works fine.
> I've installed under Win the Osgeo version, but I cannot find the qgis.core,
> only the C:/Osgeo/app/qgis/python/qgis/ folder, which contains only
> qgis_core.pyd and qgis_gui.pyd.
>
> Mmmmm! I don't understand as you can solve, but I'll try in other way!
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
-----------
|\__
(:>__)(
|/
Soluciones Geoinform?ticas Libres
http://geotux.tuxfamily.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20091130/242b7116/attachment.html
------------------------------
_______________________________________________
Qgis-developer mailing list
Qgis-developer at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
End of Qgis-developer Digest, Vol 45, Issue 63
**********************************************
More information about the Qgis-developer
mailing list