[Qgis-developer] Re: QGis & Python

Mon Nov 30 16:50:21 EST 2009

Angelica,

I just have two words to say :

It WORKS ! You're my boss ! Thank you very much !

Pierre

2009/11/30 Echavarria Gregory, Maria Angelica <
m.echavarriagregory at umiami.edu>

>
> 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
> **********************************************
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20091130/229eab49/attachment-0001.html