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