Re: [Qgis-developer] new plugin repo online
2011/3/5 Paolo Cavallini > Il giorno sab, 05/03/2011 alle 10.17 +0100, Alessandro Pasotti ha > scritto: > > > I cannot see dramatic advantages of an uploading function from within > > QGIS. BTW this could be quite easily done with a RPC call (RPC4Django > > handles this quite well). > > I agree this is not the main point. The main thing is to have to do only > one operation to publish a plugin, not a series (preparing the zip, > uploading it, adding a redmine project, adding a git project, etc.). > Could you please add your thoughts to the roadmap, not to be forgotten? > http://www.qgis.org/wiki/PluginRepository Thanks. > -- > http://www.faunalia.it/pc > > Paolo, It seems like your thoughts are quite different than mine IMHO it would be sufficient to create a QGIS plugin that helps in the packaging and uploading phase. But it seems you want to go further and have a mechanism to automate the initial creation of a plugin development infrastructure (git, redmine etc). This is a much more complex task and implies some (to be carefully evaluated) interaction with other components (like git or redmine) with all security and system-level problems. So, I will add a note on the wiki about the first phase but it's better if you add a detailed description about what's in your mind about the second phase. I remember a discussion in September about this, but I cannot remember that we reached a decision about where to go. I agree that having an easy way to setup all the stuff will stimulate people to use it. But are we sure that every plugin author will be willing to use all the machinery (git, redmine etc.) ? Can we use this time (before the hackfest) to talk about and reach a decision about this further improvements of the plugins website ? -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new plugin repo online
Il giorno lun, 07/03/2011 alle 09.14 +0100, Alessandro Pasotti ha scritto: > Can we use this time (before the hackfest) to talk about and reach a > decision about this further improvements of the plugins website ? If we do not reach a firm conclusion about this before, I think the HF is our best chance. All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 1.7 Name
W dniu 06.03.2011 10:53, Tim Sutton pisze: Hi On Sun, Mar 6, 2011 at 9:08 AM, Paolo Cavallini wrote: Il giorno sab, 05/03/2011 alle 23.39 +0200, Tim Sutton ha scritto: just pick something :-) Now I've become kind of partial to the splash screen in trunk. It includes many people from the developer community, is aptly shaped as a Q to represent QGIS, and its kinda fun. +1 - people during courses seem quite interested in it, it is nice to see real people behind the software we are using. Would it be possible to have a non-stretched version? Ah but it makes me look a lot less skinny :-) Robert do you have the original pic that you can supply me with so I can try to make a non stretched version? This is not my picture. Maris did it? Robert ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new plugin repo online
Hi By the way I just wanted to add that the process of registering a plugin from within QGIS can easily be achieved just by popping up a QWebView control with url pointed to the appropriate page. I am using this same technique for a 'first run' wizard I am working on that will allow the user to register on the users map. Regards Tim On Mon, Mar 7, 2011 at 10:25 AM, Paolo Cavallini wrote: > Il giorno lun, 07/03/2011 alle 09.14 +0100, Alessandro Pasotti ha > scritto: >> Can we use this time (before the hackfest) to talk about and reach a >> decision about this further improvements of the plugins website ? > > If we do not reach a firm conclusion about this before, I think the HF > is our best chance. > All the best. > -- > http://www.faunalia.it/pc > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [Qgis-user] PostGIS viewer -PgAdmin plugin
2011/3/6 Germán Carrillo : > Hi all, > I have added some functionalities to the plugin [1], now it: > * Has PostGIS rasters (WKTRaster) support (Based on WKTRaster QGIS plugin.) > * Has a layer list widget displaying a number of layer properties. > On the other hand, the antialiasing feature has been enabled (according to > the thread opened in the dev mailing-list) and the map units detection has > been checked and fixed (thanks Ivan). > Regards, > Germán Perfect, I have pushed Your work to 'master' branch in Github repo (with some changes: see git log) and also added You to contributors, so You have write permissions. Push Your further work there or fork me. Ivan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
Martin, have You found some good solution for threading problems in Python (threading branch) ? Ivan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
On Mon, Mar 7, 2011 at 11:20 AM, Ivan Mincik wrote: > Martin, have You found some good solution for threading problems in > Python (threading branch) ? Yes, I have fixed that few weeks ago. But the problems I am facing now are related to compatibility - I was unable to reach 100% compatibility with vector layer API until now. The functions select() and nextFeature() in both QgsVectorLayer and QgsVectorDataProvider may cause various problems with threading. I have implemented a new approach with QgsFeatureIterator class which encapsulates these methods and they should be safe. We need to support those original API methods, but they may cause havoc when they are run while rendering in threads. QGIS application can be simple modified to use just the new (safe) API using QgsFeatureIterator, but what about all the plugins?? Therefore I wonder if the merge shouldn't be postponed until we start transition to 2.0, otherwise we may end up with either deadlocks or data corruptions. (Yes, threads are evil.) Other possibility would be to merge just stuff that is safe to merge (various optimizations and refactorings) and keep back the threading until we can break backward compatibility. Comments? Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] .ui file for QgisApp
Hi devs recently I wondered why we still have the whole QGIS app gui construction (actions, menus, toolbars) in the QgisApp class. I remember that in the early Qt4 days this was necessary since there was no support in Qt Designer to create menus/toolbars. But nowadays it is perfectly possible, so for me it makes sense to move that part of code to a .ui file and use the usual setupUi() call for the main window. That could save up to 1000 lines of code in the QgisApp class! Any objections? Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] .ui file for QgisApp
When I first started working on qgis I wondered why all that code was there and not in the ui file. +1 for moving it all to the ui file. Would make things a lot nicer and cleaner to edit. On Mon, Mar 7, 2011 at 8:41 PM, Martin Dobias wrote: > Hi devs > > recently I wondered why we still have the whole QGIS app gui > construction (actions, menus, toolbars) in the QgisApp class. I > remember that in the early Qt4 days this was necessary since there was > no support in Qt Designer to create menus/toolbars. But nowadays it is > perfectly possible, so for me it makes sense to move that part of code > to a .ui file and use the usual setupUi() call for the main window. > That could save up to 1000 lines of code in the QgisApp class! > > Any objections? > > Martin > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] qt sold to Digia
seems like qt (the commercial part) is now sold to a finnish company named digia. I don't know anything about digia, but it is probably good that Nokia let go of qt instead of letting it slowly die ... http://blog.qt.nokia.com/ not much mention about the open source part of qt. Andreas -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Sun, 2011-03-06 at 11:01 -0800, Bob and Deb wrote: > I know that the Value Tool is a 3rd party plugin, but it would be nice > if the raster-provider could work with it. All of my rasters are > reported as being "out of extent". The value tool plugin is so useful (and fundamental) when doing raster analysis that I wish to see it become "core" one of these days. -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
Hi Martin On Mon, Mar 7, 2011 at 12:34 PM, Martin Dobias wrote: > On Mon, Mar 7, 2011 at 11:20 AM, Ivan Mincik wrote: >> Martin, have You found some good solution for threading problems in >> Python (threading branch) ? > > Yes, I have fixed that few weeks ago. > > But the problems I am facing now are related to compatibility - I was > unable to reach 100% compatibility with vector layer API until now. > The functions select() and nextFeature() in both QgsVectorLayer and > QgsVectorDataProvider may cause various problems with threading. I > have implemented a new approach with QgsFeatureIterator class which > encapsulates these methods and they should be safe. We need to support > those original API methods, but they may cause havoc when they are run > while rendering in threads. QGIS application can be simple modified to > use just the new (safe) API using QgsFeatureIterator, but what about > all the plugins?? > > Therefore I wonder if the merge shouldn't be postponed until we start > transition to 2.0, otherwise we may end up with either deadlocks or > data corruptions. (Yes, threads are evil.) > > Other possibility would be to merge just stuff that is safe to merge > (various optimizations and refactorings) and keep back the threading > until we can break backward compatibility. > > Comments? > Is it not possible to reimplement the old methods as thin wrappers around the new QgsFeatureIterator class and at the same time mark them in doxygen as deprecated? Sorry I havent looked in the code itself so it may be a dumb question. With regards to API backwards comptability, we have been pretty good at maintaining it to now, though its a thing we strive for and not absolutely guarantee and if our docs / wiki etc say otherwise we should adjust them. The one time we broke it in the 1.x series was because we had no other choice IIRC. For me getting your work into trunk now is important as it will give us a window of around 6 months for it to be 'gorilla tested' by 100k+ users out there before we release it in 2.0. An alternative option is that we just freeze our 'stable' releases at 1.6 (or maybe a last 1.7 release with no threading) and jump right on to doing 1.9.x releases in the run up to September. However I would rather put the things we are developing into mainstream releases since (I know some people hate this idea) our users are also our testers. Regards Tim > Regards > Martin > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] .ui file for QgisApp
Hi +1 from meit was really fun building that whole mainwindow by handin a masochistic kind of waylets not perpetuate the 'fun' if we don't need to... Regards Tim On Mon, Mar 7, 2011 at 12:57 PM, Nathan Woodrow wrote: > When I first started working on qgis I wondered why all that code was there > and not in the ui file. > +1 for moving it all to the ui file. Would make things a lot nicer and > cleaner to edit. > > On Mon, Mar 7, 2011 at 8:41 PM, Martin Dobias wrote: >> >> Hi devs >> >> recently I wondered why we still have the whole QGIS app gui >> construction (actions, menus, toolbars) in the QgisApp class. I >> remember that in the early Qt4 days this was necessary since there was >> no support in Qt Designer to create menus/toolbars. But nowadays it is >> perfectly possible, so for me it makes sense to move that part of code >> to a .ui file and use the usual setupUi() call for the main window. >> That could save up to 1000 lines of code in the QgisApp class! >> >> Any objections? >> >> Martin >> ___ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Other possibility would be to merge just stuff that is safe to merge > (various optimizations and refactorings) and keep back the threading > until we can break backward compatibility. > > Comments? Thanks for information, great that You solved GIL issues. On the other hand, I see Python plugins as killer feature in QGIS, so any un-user friendly breakage there is really bad idea, even if it will move on development. I think keeping big features like threading for version 1.9-2.0 with long testing period will bring better light on QGIS project than featurefull, but problematic version now. Thanks for Your great work. - -- Ivan Mincik, Gista s.r.o. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk103hgACgkQVqso/9cUsCyUwgCcC/AejF8JFbYaLW7RaGYjNAia mt0An34A5DY+gavk4g/Hm980BtwtSuq7 =ySbL -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
Il giorno lun, 07/03/2011 alle 15.18 +0200, Tim Sutton ha scritto: > to doing 1.9.x releases in the run up to September. However I would > rather put the things we are developing into mainstream releases since > (I know some people hate this idea) our users are also our testers. Agreed, even if it is true some people hate us because of this. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
Hi Tim! On Mon, Mar 7, 2011 at 2:18 PM, Tim Sutton wrote: > > Is it not possible to reimplement the old methods as thin wrappers > around the new QgsFeatureIterator class and at the same time mark them > in doxygen as deprecated? Sorry I havent looked in the code itself so > it may be a dumb question. This is how it is already done in the branch. But that's not enough for the compatibility. The iterator classes always lock their source of data (layer/provider) in order to make sure that only one thread accesses the data. So far so good. Now imagine that we are running rendering of several vector layers (A,B,C) in a separate thread. The rendering of A and B is in progress, rendering of C is waiting. Now the user triggers an action in GUI that starts iterating over layer C (using nextFeature() calls). If it iterates just over few features, the layer C will stay locked (expecting that more features will be fetched). Rendering of layer C will therefore get stuck waiting for the lock - infinitely. This is probably not the most common scenario, but having cases like this might severly disturb the vector access in some cases. > With regards to API backwards comptability, we have been pretty good > at maintaining it to now, though its a thing we strive for and not > absolutely guarantee and if our docs / wiki etc say otherwise we > should adjust them. The one time we broke it in the 1.x series was > because we had no other choice IIRC. For me getting your work into > trunk now is important as it will give us a window of around 6 months > for it to be 'gorilla tested' by 100k+ users out there before we > release it in 2.0. > > An alternative option is that we just freeze our 'stable' releases at > 1.6 (or maybe a last 1.7 release with no threading) and jump right on > to doing 1.9.x releases in the run up to September. However I would > rather put the things we are developing into mainstream releases since > (I know some people hate this idea) our users are also our testers. I am not sure where to go from here. I think recently we had quite decent releases with mostly stable features. This is a bit different situation where we are one week before the feature freeze for 1.7 release - merging such amount of changes in core libraries seems quite risky. I think if the threaded rendering appears in early 1.9.x releases it should get quite a lot of testing anyway. Anyway, my impression is that 90% of bug reports are from people who use the most recent version (if not svn trunk). Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
On Mon, Mar 7, 2011 at 2:37 PM, Paolo Cavallini wrote: > Il giorno lun, 07/03/2011 alle 15.18 +0200, Tim Sutton ha scritto: > >> to doing 1.9.x releases in the run up to September. However I would >> rather put the things we are developing into mainstream releases since >> (I know some people hate this idea) our users are also our testers. > > Agreed, even if it is true some people hate us because of this. Well, microsoft has been always beta-testing software on their _paying_ users for more than two decades - and look how successful they have been with that strategy :-D Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] OGR converter plugin
Hi, On Fri, 2011-03-04 at 19:02 +0200, Tim Sutton wrote: > Hi > Agreed Ill remove it - now is the time to start cleaning house on the > way to 2.0... people find also weird that the north arrow, barscale and copyright are available as plugins... can they e part of this "house cleaning" and pass them as standard options? cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] .ui file for QgisApp
On Mon, Mar 7, 2011 at 2:24 PM, Tim Sutton wrote: > Hi > > +1 from meit was really fun building that whole mainwindow by > handin a masochistic kind of waylets not perpetuate the 'fun' > if we don't need to... One more thing: I would also suggest removing status bar tips from the actions - they have exactly the same wording like action text / tooltip in most cases. And I wonder who would actually look into status bar for some help for the actions :-) Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] OGR converter plugin
Hi On Mon, Mar 7, 2011 at 3:50 PM, Giovanni Manghi wrote: > Hi, > > On Fri, 2011-03-04 at 19:02 +0200, Tim Sutton wrote: >> Hi >> Agreed Ill remove it - now is the time to start cleaning house on the >> way to 2.0... > > > people find also weird that the north arrow, barscale and copyright are > available as plugins... can they e part of this "house cleaning" and > pass them as standard options? > This is planned - I dont know if it will be for 1.7. I plan to add a new menu called 'Map' where such things can be accessed - and they will be moved into core functionality. Regards Tim > cheers > > -- Giovanni -- > > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
Hi On Mon, Mar 7, 2011 at 3:49 PM, Martin Dobias wrote: > On Mon, Mar 7, 2011 at 2:37 PM, Paolo Cavallini wrote: >> Il giorno lun, 07/03/2011 alle 15.18 +0200, Tim Sutton ha scritto: >> >>> to doing 1.9.x releases in the run up to September. However I would >>> rather put the things we are developing into mainstream releases since >>> (I know some people hate this idea) our users are also our testers. >> >> Agreed, even if it is true some people hate us because of this. > > Well, microsoft has been always beta-testing software on their > _paying_ users for more than two decades - and look how successful > they have been with that strategy :-D I suggest then if we are unsure, that we leave it out for 1.7 unless you want to make a renderer2 to go with symbology2 and labelling2...heheh :-) Only kidding. Based on the preceeding discussion I would then suggest we make 1.7 our last stable release before 2 and embark on 1.9.x unstable releases running up to sept. Regards Tim > > Martin > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
Hi > An alternative option is that we just freeze our 'stable' releases at > 1.6 (or maybe a last 1.7 release with no threading) and jump right on > to doing 1.9.x releases in the run up to September. However I would > rather put the things we are developing into mainstream releases since > (I know some people hate this idea) our users are also our testers. We already have a number of new features for 1.7 (hopefully including the raster provider branch). So for me it would be ok to have 1.7 as the last API compatible release and doing the threading branch merge just after the branching for 1.7. Anyway, it would be good to merge the changes from trunk into the threading branch already now. Like this, people who need e.g. the globe plugin could work with the threading branch sources until 1.7 is branched. Additionally, it is easier to test the threading branch in productive work with all the fixes and new features from trunk. Regards, Marco Am Montag, 7. März 2011, um 14.18:15 schrieb Tim Sutton: > Hi Martin > > On Mon, Mar 7, 2011 at 12:34 PM, Martin Dobias wrote: > > On Mon, Mar 7, 2011 at 11:20 AM, Ivan Mincik wrote: > >> Martin, have You found some good solution for threading problems in > >> Python (threading branch) ? > > > > Yes, I have fixed that few weeks ago. > > > > But the problems I am facing now are related to compatibility - I was > > unable to reach 100% compatibility with vector layer API until now. > > The functions select() and nextFeature() in both QgsVectorLayer and > > QgsVectorDataProvider may cause various problems with threading. I > > have implemented a new approach with QgsFeatureIterator class which > > encapsulates these methods and they should be safe. We need to support > > those original API methods, but they may cause havoc when they are run > > while rendering in threads. QGIS application can be simple modified to > > use just the new (safe) API using QgsFeatureIterator, but what about > > all the plugins?? > > > > Therefore I wonder if the merge shouldn't be postponed until we start > > transition to 2.0, otherwise we may end up with either deadlocks or > > data corruptions. (Yes, threads are evil.) > > > > Other possibility would be to merge just stuff that is safe to merge > > (various optimizations and refactorings) and keep back the threading > > until we can break backward compatibility. > > > > Comments? > > Is it not possible to reimplement the old methods as thin wrappers > around the new QgsFeatureIterator class and at the same time mark them > in doxygen as deprecated? Sorry I havent looked in the code itself so > it may be a dumb question. > > With regards to API backwards comptability, we have been pretty good > at maintaining it to now, though its a thing we strive for and not > absolutely guarantee and if our docs / wiki etc say otherwise we > should adjust them. The one time we broke it in the 1.x series was > because we had no other choice IIRC. For me getting your work into > trunk now is important as it will give us a window of around 6 months > for it to be 'gorilla tested' by 100k+ users out there before we > release it in 2.0. > > An alternative option is that we just freeze our 'stable' releases at > 1.6 (or maybe a last 1.7 release with no threading) and jump right on > to doing 1.9.x releases in the run up to September. However I would > rather put the things we are developing into mainstream releases since > (I know some people hate this idea) our users are also our testers. > > Regards > > Tim > > > Regards > > Martin > > ___ > > Qgis-developer mailing list > > Qgis-developer@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
Hi Marco On Mon, Mar 7, 2011 at 4:11 PM, Marco Hugentobler wrote: > Hi > >> An alternative option is that we just freeze our 'stable' releases at >> 1.6 (or maybe a last 1.7 release with no threading) and jump right on >> to doing 1.9.x releases in the run up to September. However I would >> rather put the things we are developing into mainstream releases since >> (I know some people hate this idea) our users are also our testers. > > We already have a number of new features for 1.7 (hopefully including the > raster provider branch). So for me it would be ok to have 1.7 as the last API > compatible release and doing the threading branch merge just after the > branching for 1.7. Agreed. > Anyway, it would be good to merge the changes from trunk into the threading > branch already now. Like this, people who need e.g. the globe plugin could > work with the threading branch sources until 1.7 is branched. Additionally, it > is easier to test the threading branch in productive work with all the fixes > and new features from trunk. I thought I will do it the other way round: to create a new branch from trunk (e.g. threading_branch2) and merge the commits from threading_branch there. Looks easier to port those few dozens of commits rather than porting nearly 2000(!) commits from trunk back to the branch. Btw. what functionality from threading branch is required by the globe plugin? Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] In with the new, out with the old?
Hi Devs, One of my favorite outcomes from developing fTools, is actually when one or two fTools functions become redundant due to new features in base QGIS. The reason isn't because that means one less tool for me to worry about, but rather because it means things are progressing... and with QGIS things are progressing big time! In that vein, I would like to propose several tool 'retirements' from fTools. While I tend to feel that several ways to do the same thing is helpful/good, it can also get confusing if those different procedures produce varying results. As such, I think it would be appropriate to retire the following tools: - Export/add geometry columns (this can now be done quite easily from the field calculator, and my version appears to have issues with certain vector formats) - Export to new projection (this can now be achieved by "Sav[ing] a layer as...") - Join attributes (this was never really meant as a 'solution', but rather a temporary 'hack' to allow for table joints, but it is slow and combersome, and requires the creation of a new field, whereas the new join capabilities are excellent, fast, and excellent!) - fTools information (nobody needs to know what fTools is anymore, and frankly, this info should really be part of the help system and documentation... also, I think this dialog often interferes with help/about on macs?) Some other potential 'retirees' are: - Select by location (I think there is a 'Spatial Query' plugin which has this functionality plus much more, and appears to be quite fast) - Define current projection (Is this covered by the new 'Set CRS of Layer(s)' tool? I haven't had much of a play with this one yet, but it sounds like it should, and is more convenient being part of the main GUI) Let me know what you think. Should these be completely retired, or should they perhaps just be wrappers around their replacements to keep things familiar? I think I'd be leaning more towards full retirement, which should hopefully promote doing things 'the right way' (i.e. using the new core QGIS functionality). Regards, Carson -- Carson J. Q. Farmer ISSP Doctoral Fellow National Centre for Geocomputation National University of Ireland, Maynooth, http://www.carsonfarmer.com/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Hi Carson, > - Export/add geometry columns (this can now be done quite easily from > the field calculator, and my version appears to have issues with > certain vector formats) the field calculator misses to compute the perimeter of the polygons. Once it will do it you can retire "Export/add geometry columns" ;) cheers! -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Il giorno lun, 07/03/2011 alle 18.16 +, Carson Farmer ha scritto: > - Export/add geometry columns (this can now be done quite easily from > the field calculator, and my version appears to have issues with > certain vector formats) I find your solution more intuitive for newbies, and I would like to keep it, at least for now. Can calculator extract x and y from points? > - Export to new projection (this can now be achieved by "Sav[ing] a > layer as...") Agreed. > - Join attributes (this was never really meant as a 'solution', but > rather a temporary 'hack' to allow for table joints, but it is slow > and combersome, and requires the creation of a new field, whereas the > new join capabilities are excellent, fast, and excellent!) Agreed. > - fTools information (nobody needs to know what fTools is anymore, and > frankly, this info should really be part of the help system and > documentation... also, I think this dialog often interferes with > help/about on macs?) It is a piece of history, and it is nice to give credits to your work, but it is true that now it seems a bit out of place. > - Select by location (I think there is a 'Spatial Query' plugin which > has this functionality plus much more, and appears to be quite fast) Right, even though the spatial query is more complex to use. > - Define current projection (Is this covered by the new 'Set CRS of > Layer(s)' tool? I haven't had much of a play with this one yet, but it > sounds like it should, and is more convenient being part of the main > GUI) AFAIK, the properties define a projection at runtime, whereas your tool actually writes a prj file. Am I wrong? BTW, I think now fTools could often avoid writing new shapefiles, just adding the new info on the existing layer instead (e.g. points in polygons, etc.). Would this be hard? All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
> Can calculator extract x and y from points? right, the calculator also misses this feature. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Dnia poniedziałek 07 marca 2011 o 19:28:09 Giovanni Manghi napisał(a): > Hi Carson, > > > - Export/add geometry columns (this can now be done quite easily from > > the field calculator, and my version appears to have issues with > > certain vector formats) > > the field calculator misses to compute the perimeter of the polygons. > Once it will do it you can retire "Export/add geometry columns" ;) And - ihmo much more important - x,y coords for point layers ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
> the field calculator misses to compute the perimeter of the polygons. > Once it will do it you can retire "Export/add geometry columns" ;) Ok, I'll have a look at that tonight then Carson -- Carson J. Q. Farmer ISSP Doctoral Fellow National Centre for Geocomputation National University of Ireland, Maynooth, http://www.carsonfarmer.com/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
> I find your solution more intuitive for newbies, and I would like to > keep it, at least for now. Can calculator extract x and y from points? No it can't, and perimeter calculation seems to be an issue as well. Ok, well then I might change this to be a wrapper around the field calculator, that way it will be intuitive for beginners, and still have the added functionality of x and y values and perimeter. >> - Export to new projection (this can now be achieved by "Sav[ing] a >> layer as...") > > Agreed. Ok, I will remove this tonight >> - Join attributes (this was never really meant as a 'solution', but >> rather a temporary 'hack' to allow for table joints, but it is slow >> and combersome, and requires the creation of a new field, whereas the >> new join capabilities are excellent, fast, and excellent!) > > Agreed. This one I will not be sad to see gone from fTools! Good riddance ;-) >> - fTools information (nobody needs to know what fTools is anymore, and >> frankly, this info should really be part of the help system and >> documentation... also, I think this dialog often interferes with >> help/about on macs?) > > It is a piece of history, and it is nice to give credits to your work, > but it is true that now it seems a bit out of place. I'll just move all the 'credit' related info to where it belongs in the main QGIS about dialog I think. I don't like how it looks the way it is now, and for the most part, fTools is now referred to as the Vector menu, so beginners probably don't even know what fTools is > >> - Select by location (I think there is a 'Spatial Query' plugin which >> has this functionality plus much more, and appears to be quite fast) > > Right, even though the spatial query is more complex to use. Hmm, yes I tested it just now. It is a bit more complicated, but not overly so... thoughts from others? >> - Define current projection (Is this covered by the new 'Set CRS of >> Layer(s)' tool? I haven't had much of a play with this one yet, but it >> sounds like it should, and is more convenient being part of the main >> GUI) > > AFAIK, the properties define a projection at runtime, whereas your tool > actually writes a prj file. Am I wrong? True, it does write the prj file, but I'm talking about the new feature from recent builds... the tool doesn't have an icon yet... am I crazy? > > BTW, I think now fTools could often avoid writing new shapefiles, just > adding the new info on the existing layer instead (e.g. points in > polygons, etc.). > Would this be hard? Not overly hard no, and there are really only a few tools that this would apply to. One thing I'd really like to do is add the capability to output other formats besides shapefiles (I'm not a big shapefile fan these days, field name limitations are a hassle). I might try move over the geometry and geoprocessing tools first, as they seem to be the most frequently used tools. Carson -- Carson J. Q. Farmer ISSP Doctoral Fellow National Centre for Geocomputation National University of Ireland, Maynooth, http://www.carsonfarmer.com/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Hi Carson, On Mar 7, 2011, at 11:17 AM, Carson Farmer wrote: >>> - Join attributes (this was never really meant as a 'solution', but >>> rather a temporary 'hack' to allow for table joints, but it is slow >>> and combersome, and requires the creation of a new field, whereas the >>> new join capabilities are excellent, fast, and excellent!) >> >> Agreed. > This one I will not be sad to see gone from fTools! Good riddance ;-) >> Yes, but your join by location feature is exceptional and needs to remain. I don't know of any alternative to that. It has been a life saver on several occasions for me. (Think grass v.to.rect, do something r.*, r.to.vect --> oops, I know longer have attributes!) Thanks for your great contributions, as always. John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Branch status for merge and release timeline proposal
Hi Martin > I thought I will do it the other way round: to create a new branch > from trunk (e.g. threading_branch2) and merge the commits from > threading_branch there. Looks easier to port those few dozens of > commits rather than porting nearly 2000(!) commits from trunk back to > the branch. Agreed, this could be easier than the other way round. > Btw. what functionality from threading branch is required by the globe > plugin? osgEarth requests a lot of tiles from the maprenderer and it is very easy to conflict with the rendering of the qgis canvas. So afaik the main feature it needs from the branch are the feature iterators in the providers. Regards, Marco Am Montag, 7. März 2011, 16.26:19 schrieb Martin Dobias: > Hi Marco > > On Mon, Mar 7, 2011 at 4:11 PM, Marco Hugentobler > > wrote: > > Hi > > > >> An alternative option is that we just freeze our 'stable' releases at > >> 1.6 (or maybe a last 1.7 release with no threading) and jump right on > >> to doing 1.9.x releases in the run up to September. However I would > >> rather put the things we are developing into mainstream releases since > >> (I know some people hate this idea) our users are also our testers. > > > > We already have a number of new features for 1.7 (hopefully including the > > raster provider branch). So for me it would be ok to have 1.7 as the last > > API compatible release and doing the threading branch merge just after > > the branching for 1.7. > > Agreed. > > > Anyway, it would be good to merge the changes from trunk into the > > threading branch already now. Like this, people who need e.g. the globe > > plugin could work with the threading branch sources until 1.7 is > > branched. Additionally, it is easier to test the threading branch in > > productive work with all the fixes and new features from trunk. > > I thought I will do it the other way round: to create a new branch > from trunk (e.g. threading_branch2) and merge the commits from > threading_branch there. Looks easier to port those few dozens of > commits rather than porting nearly 2000(!) commits from trunk back to > the branch. > > Btw. what functionality from threading branch is required by the globe > plugin? > > Martin -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstr. 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
> Yes, but your join by location feature is exceptional and needs to remain. I > don't know of any alternative to that. agreed ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] symbol levels in rule-based rendering
Hi Martin I'm also in favour of a rule based renderer that follows closely the logic of SLD. It would be a big plus for QGIS server too. Currently, it's SLD capabilities are built on top of the old renderer, so no overpainting, etc. And yes, with a nice GUI, it will be as user-friendly as the other parts of the symbology. Regards, Marco Am Samstag, 5. März 2011, 20.12:04 schrieb Martin Dobias: > Hi Mayeul > > On Wed, Mar 2, 2011 at 6:01 PM, wrote: > > Hi, > > > > (This follows this thread: Branch status for merge and release timeline > > proposal) > > > > Thanks for you answer Tim! I found the clarification useful and I > > appreciate your sense of diplomacy. Here are a few thoughts. > > > > You wrote: "I agree the items in your list should get attention" > > Just to make sure: most of the list (including links to my patch) was > > written by users Neumann and Anitagraser. > > > > Among those fixes, we are several developers to believe that symbol > > levels in rule-based rendering should be fixed, even with a temporary > > fix. A fix was proposed in August 2010 by mhugent, see: > > http://trac.osgeo.org/qgis/ticket/2832#comment:8 > > His patch was applied except for the symbol level lines (about 10 lines > > of code). > > > > I made improvements to this code and my patch was somehow applied, again > > without the few symbol level lines of code. > > http://trac.osgeo.org/qgis/ticket/3222#comment:15 > > > > I agree with Martin that it would be better to have a final solution than > > an incomplete one for symbol levels. But since the rule-based rendering > > is currently in an incomplete state, why put it in the renderer stable > > release anyway? I believe symbol levels make a huge difference in > > rendering lines. With them, I have a rendering similar to Osmarender or > > Mapnik in QGIS which gives QGIS a definitive bonus with respect to many > > other desktop or server GIS. (for a rendering sample, see: > > http://www.qgis.org/qgiswiki/images/f/fd/Lago_di_varese.png > > which is compared with the OSM python plugin rendering here: > > http://www.qgis.org/wiki/Using_OpenStreetMap_data ) > > > > Also, QGIS rule-based rendering is definitely more powerful than what you > > can achieve on ArcGIS with queries and scale-related visibility, but > > ArcGIS users who need symbol levels will not want QGIS's rule-based > > rendering. > > > > Ideally we should be able to have any combinations of the following: > > -symbol levels ON or OFF > > -apply first matching rule or apply all rules > > (That's 4 combinations) > > Short version of my brain dump below: I don't see a reason why we > should support "apply first matching rule" because it would complicate > the whole renderer with virtually no added value. And I am not yet > sure what to do with the symbol levels issue. Interested readers > please continue reading :-) > > Recently I have been thinking about the rule-based renderer a lot. The > symbol levels is not the only thing that needs our attention. I think > we all agree that ultimately we want to have some kind of > compatibility with SLD and/or Mapnik which (to my knowledge) are quite > compatible between each other. To summarize how they work: > - each (vector) layer is assigned one or more styles > - each style consists of a set of rules > - each rule consists of a scale range, a filter and one or more symbolizers > - a filter either matches all features or matches only features > according a query. There's also "else" filter that matches only if all > other rules do not match. > When rendering a vector layer, styles are rendered in the order they > appear in the input file. When rendering a style, for each feature > each rule is checked and the symbolizers are applied if the rule > matches. > > Now let's face what we have in our rule-based renderer: > - a symbol layer is basically a symbolizer, a group of symbolizers > makes a symbol > - rule has the same meaning as in SLD/Mapnik, but there is no else filter > - there is nothing like style in the sense of SLD/Mapnik > > So if you are drawing roads with outlines (our typical use case) in > SLD/Mapnik you can do this: > Style1 > - Rule1 > - Line symbolizer1 > - Line symbolizer2 > This will have the same effect as drawing without symbol levels > enabled: the rule is rendered at once for each feature. To get "symbol > levels" effect you need to do this: > Style1 > - Rule1 > - Line symbolizer1 > Style2 > - Rule2 > - Line symbolizer2 > First style1 is rendered, then style2 is rendered, getting the expected > effect. > > I wondered if we shouldn't introduce the notion "styles" in the > meaning of SLD/Mapnik for the rule-based renderer. That would mean > that the rules would be grouped into "styles", which would have > several implications: > - there would be no need to explicitly define symbol levels since the > effect would be attained in the way described above. > - this would also make possible to have just one painting algor
Re: [Qgis-developer] Branch status for merge and release timeline proposal
Hi Martin, Marco was quicker, but here is my answer as well... Am Montag, 7. März 2011, um 16.26:19 schrieb Martin Dobias: > Hi Marco > > On Mon, Mar 7, 2011 at 4:11 PM, Marco Hugentobler > > wrote: > > Hi > > > >> An alternative option is that we just freeze our 'stable' releases at > >> 1.6 (or maybe a last 1.7 release with no threading) and jump right on > >> to doing 1.9.x releases in the run up to September. However I would > >> rather put the things we are developing into mainstream releases since > >> (I know some people hate this idea) our users are also our testers. > > > > We already have a number of new features for 1.7 (hopefully including the > > raster provider branch). So for me it would be ok to have 1.7 as the last > > API compatible release and doing the threading branch merge just after > > the branching for 1.7. > > Agreed. > > > Anyway, it would be good to merge the changes from trunk into the > > threading branch already now. Like this, people who need e.g. the globe > > plugin could work with the threading branch sources until 1.7 is > > branched. Additionally, it is easier to test the threading branch in > > productive work with all the fixes and new features from trunk. > > I thought I will do it the other way round: to create a new branch > from trunk (e.g. threading_branch2) and merge the commits from > threading_branch there. Looks easier to port those few dozens of > commits rather than porting nearly 2000(!) commits from trunk back to > the branch. > > Btw. what functionality from threading branch is required by the globe > plugin? The globe plugin reads the layer list and calls the QGIS to render tiles and draping them on the globe. Since this is done in a separate window, a refresh in the 2D map window crashes QGIS as long as parallel rendering is not supported. Using locks during rendering is more difficult than e.g. from the print composer because there are many more calls and the globe engine is running multiple threads itself. Pirmin -- Pirmin Kalberer Sourcepole - Linux & Open Source Solutions http://www.sourcepole.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi Radim Great! +1 for merging from me too. Regards, Marco Am Sonntag, 6. März 2011, 21.18:59 schrieb Radim Blazek: > Hi, > I am ready to merge raster-providers branch to trunk. Are you ready too? > > Radim > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstr. 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Hi Carson On Mon, 7 Mar 2011 18:16:23 + Carson Farmer wrote: > - Export/add geometry columns (this can now be done quite easily from > the field calculator, and my version appears to have issues with > certain vector formats) Starting with r15381 Field calculator can extract X, Y and perimeter, so I think this tool can be removed > > BTW, I think now fTools could often avoid writing new shapefiles, just > > adding the new info on the existing layer instead (e.g. points in > > polygons, etc.). > > Would this be hard? > Not overly hard no, and there are really only a few tools that this > would apply to. > > One thing I'd really like to do is add the capability to output other > formats besides shapefiles (I'm not a big shapefile fan these days, > field name limitations are a hassle). I might try move over the > geometry and geoprocessing tools first, as they seem to be the most > frequently used tools. Maybe it is better to create in-memory layer and let user to save it in some desired format using Save As... option from layer context menu? -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
> Starting with r15381 Field calculator can extract X, Y and perimeter, > so I think this tool can be removed Just a thought - x and y in the field calculator require a couple of clicks. In the ftools you can do it by one click... > > One thing I'd really like to do is add the capability to output other > > formats besides shapefiles (I'm not a big shapefile fan these days, > > field name limitations are a hassle). I might try move over the > > geometry and geoprocessing tools first, as they seem to be the most > > frequently used tools. > > Maybe it is better to create in-memory layer and let user to save it in > some desired format using Save As... option from layer context menu? H implementing other file formats to the QgsVectorFileWriter is quite easy, while AFAIK writing to the memory layer requires another approach. Maybe we should encapsulate the QgsVectorFileWriter to provide an universal class for the 1.7 API? Just a thought - it's late and my brain is busy with a few other threads ;) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
>> > One thing I'd really like to do is add the capability to output other >> > formats besides shapefiles (I'm not a big shapefile fan these days, >> > field name limitations are a hassle). I might try move over the >> > geometry and geoprocessing tools first, as they seem to be the most >> > frequently used tools. >> >> Maybe it is better to create in-memory layer and let user to save it in >> some desired format using Save As... option from layer context menu? > > H implementing other file formats to the QgsVectorFileWriter is quite > easy, while AFAIK writing to the memory layer requires another approach. Maybe > we should encapsulate the QgsVectorFileWriter to provide an universal class > for the 1.7 API? Just a thought - it's late and my brain is busy with a few > other threads ;) My preference would be to add the capability to write to other formats. Writing to a memory layer can become unwieldy when working with large layers (which is common with geoprocessing operations). Carson -- Carson J. Q. Farmer ISSP Doctoral Fellow National Centre for Geocomputation National University of Ireland, Maynooth, http://www.carsonfarmer.com/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Dnia niedziela 06 marca 2011 o 21:18:59 Radim Blazek napisał(a): > Hi, > I am ready to merge raster-providers branch to trunk. Are you ready too? > > Radim Just to let you know, some of us are looking forward :-) There's less and less time for testing :) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
> > H implementing other file formats to the QgsVectorFileWriter is quite > > easy, while AFAIK writing to the memory layer requires another approach. > > Maybe we should encapsulate the QgsVectorFileWriter to provide an > > universal class for the 1.7 API? Just a thought - it's late and my brain > > is busy with a few other threads ;) > > My preference would be to add the capability to write to other > formats. Writing to a memory layer can become unwieldy when working > with large layers (which is common with geoprocessing operations). Actually I think there's no simple answer what is better. I prefer to use memory layers as long as it's possible. So I'd prefer to see three options: - save to memory layer [...name...] and add to the canvas - save to file [...path...] and add to the canvas - save to file [...path...] and don't add to the canvas Btw. When saving to files, kinda garbage collector would be extremely usable:) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
> Btw. When saving to files, kinda garbage collector would be extremely usable:) Garbage collector? You mean memory-wise, or temporary file type garbage? -- Carson J. Q. Farmer ISSP Doctoral Fellow National Centre for Geocomputation National University of Ireland, Maynooth, http://www.carsonfarmer.com/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
I would like to see one more option on that list: - Save to current selected layer This would write straight back to the current selected layer. I don't always want a new layer when doing things like buffers etc. - Nathan On Tue, Mar 8, 2011 at 8:29 AM, Borys Jurgiel wrote: > > > H implementing other file formats to the QgsVectorFileWriter is > quite > > > easy, while AFAIK writing to the memory layer requires another > approach. > > > Maybe we should encapsulate the QgsVectorFileWriter to provide an > > > universal class for the 1.7 API? Just a thought - it's late and my > brain > > > is busy with a few other threads ;) > > > > My preference would be to add the capability to write to other > > formats. Writing to a memory layer can become unwieldy when working > > with large layers (which is common with geoprocessing operations). > > Actually I think there's no simple answer what is better. I prefer to use > memory layers as long as it's possible. So I'd prefer to see three options: > > - save to memory layer [...name...] and add to the canvas > - save to file [...path...] and add to the canvas > - save to file [...path...] and don't add to the canvas > > Btw. When saving to files, kinda garbage collector would be extremely > usable:) > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Dnia poniedziałek 07 marca 2011 o 23:31:28 Carson Farmer napisał(a): > > Btw. When saving to files, kinda garbage collector would be extremely > > usable:) > > Garbage collector? You mean memory-wise, or temporary file type garbage? temporary files :) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Dnia poniedziałek 07 marca 2011 o 23:32:21 Nathan Woodrow napisał(a): > I would like to see one more option on that list: > >- Save to current selected layer > > This would write straight back to the current selected layer. I don't > always want a new layer when doing things like buffers etc. +1 And it should be probably implemented in qgis libs for easy use in plugins. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
On Mon, Mar 7, 2011 at 10:33 PM, Borys Jurgiel wrote: > Dnia poniedziałek 07 marca 2011 o 23:31:28 Carson Farmer napisał(a): >> > Btw. When saving to files, kinda garbage collector would be extremely >> > usable:) >> >> Garbage collector? You mean memory-wise, or temporary file type garbage? > > temporary files :) > So a tool to delete vector(s)/raster(s) and associated files. Something like a open file dialog where you can select x number of QGIS supported vector/raster files, and delete them all in one go? That *would* be handy... C -- Carson J. Q. Farmer ISSP Doctoral Fellow National Centre for Geocomputation National University of Ireland, Maynooth, http://www.carsonfarmer.com/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
RE: [Qgis-developer] In with the new, out with the old?
Yes please to this option (fTools writing to a memory layer)!! I was thinking of coding for a couple of the fTools functions I used myself. It would be great to have it in fTools by default :-) Note: I've uploaded a memory saver plugin that allows memory layers to be persisted alongside the project file (MemoryLayerSaver plugin). In discussing this before I've suggested that this should really be a core function .. The memory layers shouldn't disappear without warning when you save and reopen a project. This provoked some discussion and different points of view. For example where and in what format should the memory layer data be stored. I also think that if you save a memory layer to a persistant format, then at least optionally the saved layer could replace the existing memory layer (ie replace the memory data provider with the provider for the saved version and retain the symbology and z order placement). Perhaps replacing the provider in this way should be option whenever any vector layer is saved, as memory layers don't look different to any other to the user. Moving to using the memory layers as a working layer for tools would make this a much more valuable enhancement. Cheers Chris -Original Message- From: Alexander Bruy [mailto:alexander.b...@gmail.com] Sent: Tuesday, 8 March 2011 10:08 a.m. To: Carson Farmer Cc: Qgis Developer List Subject: Re: [Qgis-developer] In with the new, out with the old? Hi Carson On Mon, 7 Mar 2011 18:16:23 + Carson Farmer wrote: > - Export/add geometry columns (this can now be done quite easily from > the field calculator, and my version appears to have issues with > certain vector formats) Starting with r15381 Field calculator can extract X, Y and perimeter, so I think this tool can be removed > > BTW, I think now fTools could often avoid writing new shapefiles, > > just adding the new info on the existing layer instead (e.g. points > > in polygons, etc.). > > Would this be hard? > Not overly hard no, and there are really only a few tools that this > would apply to. > > One thing I'd really like to do is add the capability to output other > formats besides shapefiles (I'm not a big shapefile fan these days, > field name limitations are a hassle). I might try move over the > geometry and geoprocessing tools first, as they seem to be the most > frequently used tools. Maybe it is better to create in-memory layer and let user to save it in some desired format using Save As... option from layer context menu? -- Alexander Bruy __ This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank you. __ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Ok, but we have to be careful here... because overwriting a layer that we are currently working on could lead to problems when the data provider tries to access features that have been overwritten/erased. Also, what about the case where we have a line layer that we are buffering? Carson On Mon, Mar 7, 2011 at 10:41 PM, Borys Jurgiel wrote: > Dnia poniedziałek 07 marca 2011 o 23:32:21 Nathan Woodrow napisał(a): >> I would like to see one more option on that list: >> >> - Save to current selected layer >> >> This would write straight back to the current selected layer. I don't >> always want a new layer when doing things like buffers etc. > > +1 And it should be probably implemented in qgis libs for easy use in plugins. > -- Carson J. Q. Farmer ISSP Doctoral Fellow National Centre for Geocomputation National University of Ireland, Maynooth, http://www.carsonfarmer.com/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] How to debug and unit test Python plugins outside QGIS (e.g. in Ecplise IDE + PyDev)
Hi Stefan, All, coming from webdesign I use Aptana (eclipse derivation) with pydev with success. Eclipse itself always managed to drive me crazy for some reasons... I tried as well spe and erich and didn't like the feeling. Ggeany and gedit with many plugins are very light but Aptana/pydev is what suits my needs best. ciao Marco On 03/06/2011 06:08 PM, Stefan Keller wrote: > Hi Alex > > You wrote: >> I tried Eclipse with Pydev years back and felt that it was a dead end >> for Python programming (also a bit of a resource hog). Partly because >> all the useful stuff wasn't in the open source version, and partly >> because Eclipse was a huge memory hole for something as simple as python. > > => Which useful stuff so you mean? > > Eclipse and PyDev are open source and my Eclipse starts in about 5 > seconds on my laptop (Win XP with an Intel Centrino and uses 200MB > memory i.e. less than Firefox). > >> Eric, SPE, and Spyder all seem like better options - 2 of the 3 are >> written with PyQt also and I've gotten at least 2 of them to work with >> OSGeo4W installs (Requires launching via a batch file). > > The requirements of my "modern SW developer environment" are syntax > highlighting, autocompletion, unit testing und debugging. Eclipse > seems to deliver that. We also tested Eric4, SPE, PythonWin (Windows > only), IDLE and PyPE where Eric and SPE seem to be most promising. > Spyder, JEdit etc. are to me rather text programming editors, not > IDEs. > > Eclipse and probably all other IDEs/Editors can set PATHs to external > libraries. > => With which software did you get problems? > > @all => What Python IDEs/Editors are other QGIS developers using? > > As Martin said, it must be possible to get external compiling, > debugging and unit testing with QGIS to work since there QGIS > libraries can als be used for developing custom applications based on > QGIS API. I'll report on that. > > Yours, S. > > > 2011/3/5 Alex Mandel : >> I tried Eclipse with Pydev years back and felt that it was a dead end >> for Python programming (Also a bit of a resource hog). Partly because >> all the useful stuff wasn't in the open source version, and partly >> because Eclipse was a huge memory hole for something as simple as python. >> >> Eric, SPE, and Spyder all seem like better options - 2 of the 3 are >> written with PyQt also and I've gotten at least 2 of them to work with >> OSGeo4W installs (Requires launching via a batch file). >> >> I'm not so sure this would be a QGIS SOC project, however if it's just a >> task in say creating unit tests that would make sense. >> >> Thanks, >> Alex >> >> On 03/03/2011 12:26 AM, Stefan Keller wrote: >>> I still hope this should be an issue to be solved within reasonable >>> time given Eclipse as IDE. >>> However, yes, it could be that this turns out to be a larger endeavour. >>> I can imagine that one solution could be that Python stubs have to be >>> generated out of PyGt4/QGIS libs? >>> >>> Yours, S. >>> >>> 2011/3/3 Andreas Neumann : Couldn't this be a GSoC idea? Creating a developer-friendly Development environment for Python Developers? With a nice debugging solution, code completion, possibility to do unit tests, integration with the plugin repository, etc.? I would guess a lot of devs would gain productivity through such improved developer tools and a student could learn quite a bit in putting these together. Andreas On Thu, 3 Mar 2011 08:38:36 +0100, Stefan Keller wrote: > > Many thanks also for the hint to standalone apps.! > I still hope there is a solution to unit test QGIS plugins. > This would make QGIS programmers even more happy :-> > > Yours, S. > > > 2011/3/3 Alex Mandel : >> >> It might be possible, I'm not super familiar with units tests yet. >> The big issue I see is that most plugins rely on the main QGIS app >> providing data to the plugin or interacting with the plugin. If you can >> design the test to provide what the unit test needs then it should be >> doable. After all you can build standalone python apps with the QGIS api. >> >> Thanks, >> Alex >> >> On 03/02/2011 10:13 PM, Stefan Keller wrote: >>> >>> Hi Alex, >>> >>> Many thanks for your reply. I'll try this. >>> >>> But: So you say implicitly that its impossible to run unit tests >>> (PyUnit) on QGIS plugins? >>> I still hope there is a way to make PyGt4 module interface accessible >>> outside QGIS. At runtime its there, so it should be somehow possible >>> either by "Forced builtin libs" or by extracting the information by >>> hand with dummy stubs...? >>> >>> Yours, S. >>> >>> 2011/3/3 Alex Mandel : On 03/02/2011 03:57 PM, Stefan Keller wrote: > > Hi, > > I'm new to writing Python plugins for QGIS and I like to debug and > unit test
Re: [Qgis-developer] In with the new, out with the old?
Ok, I'm getting the overwhelming feeling that people want to be able to 'write' to memory layers. I'll try to add this functionality. However, I really don't think this should be the 'default' or primary/sole output type. I think what I'll probably do is simply add 'output options' to the current output file dialog, such that users can choose memory layer (this might require some work on a more generic vector file writer), shapefile, kml, whatever... Carson On Mon, Mar 7, 2011 at 10:43 PM, Chris Crook wrote: > Yes please to this option (fTools writing to a memory layer)!! > > I was thinking of coding for a couple of the fTools functions I used myself. > It would be great to have it in fTools by default :-) > > Note: I've uploaded a memory saver plugin that allows memory layers to be > persisted alongside the project file (MemoryLayerSaver plugin). > > In discussing this before I've suggested that this should really be a core > function .. The memory layers shouldn't disappear without warning when you > save and reopen a project. This provoked some discussion and different > points of view. For example where and in what format should the memory layer > data be stored. > > I also think that if you save a memory layer to a persistant format, then at > least optionally the saved layer could replace the existing memory layer (ie > replace the memory data provider with the provider for the saved version and > retain the symbology and z order placement). > > Perhaps replacing the provider in this way should be option whenever any > vector layer is saved, as memory layers don't look different to any other to > the user. > > Moving to using the memory layers as a working layer for tools would make > this a much more valuable enhancement. > > Cheers > Chris > > -Original Message- > From: Alexander Bruy [mailto:alexander.b...@gmail.com] > Sent: Tuesday, 8 March 2011 10:08 a.m. > To: Carson Farmer > Cc: Qgis Developer List > Subject: Re: [Qgis-developer] In with the new, out with the old? > > Hi Carson > > On Mon, 7 Mar 2011 18:16:23 + > Carson Farmer wrote: > >> - Export/add geometry columns (this can now be done quite easily from >> the field calculator, and my version appears to have issues with >> certain vector formats) > Starting with r15381 Field calculator can extract X, Y and perimeter, so I > think this tool can be removed > >> > BTW, I think now fTools could often avoid writing new shapefiles, >> > just adding the new info on the existing layer instead (e.g. points >> > in polygons, etc.). >> > Would this be hard? >> Not overly hard no, and there are really only a few tools that this >> would apply to. >> >> One thing I'd really like to do is add the capability to output other >> formats besides shapefiles (I'm not a big shapefile fan these days, >> field name limitations are a hassle). I might try move over the >> geometry and geoprocessing tools first, as they seem to be the most >> frequently used tools. > > Maybe it is better to create in-memory layer and let user to save it in some > desired format using Save As... option from layer context menu? > > -- > Alexander Bruy > > __ > > This message contains information, which is confidential and may be subject > to legal privilege. > If you are not the intended recipient, you must not peruse, use, disseminate, > distribute or copy this message. > If you have received this message in error, please notify us immediately > (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. > LINZ accepts no responsibility for changes to this email, or for any > attachments, after its transmission from LINZ. > > Thank you. > __ > -- Carson J. Q. Farmer ISSP Doctoral Fellow National Centre for Geocomputation National University of Ireland, Maynooth, http://www.carsonfarmer.com/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgsLegendInterface
Hi Marco On Thu, Mar 3, 2011 at 4:27 PM, Marco Bernasocchi wrote: > QgsLegendInterface::groupLayerRelationship() returns this: > [group0, group1, subGroupOfGroup0] > BUT > QgsLegendInterface::groups() returns: > [group0, subGroupOfGroup0, group1] > > notice the difference in the order, is this done on purpose? or a bug? I > spent couple of ours digging for the problem in my code today and it > turned out to be because I was using the indexes from groups(). The legend interface has been evolving a bit ad-hoc. I believe first there was just groups() function, then groupLayerRelationship() has been added for some other purpose and probably after all that support for sub-groups has been added. So the result is not a bug, they just a traverse the tree in a different way. > as well, if you want to have all the groups name, now you have to > iterate on groupLayerRelationship() like this: > > groups = [] > for group in self.legend.groupLayerRelationship(): > groups.append(group[0]) > > and then groups is an array with all the group names (like groups()) but > in the same order as the groupLayerRelationship(). > > I think that it would be sensible to have a method like groups() that > returns the same as my iteration above. what do you think? I would of > course do it if it is needed. I have no strong opinion on that. But I think that it would be much better to implement a method that would return the complete tree. For example, there would be a class "legend node". A node could be either a layer or a group. Layer node would reference layer (or its ID) and group node would contain a list of all children (again layers and/or groups). Legend interface would then just return a list of top-level nodes. Nothing complicated, simple for traversal and no need for extra methods. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Dnia poniedziałek 07 marca 2011 o 23:48:46 Carson Farmer napisał(a): > Ok, I'm getting the overwhelming feeling that people want to be able > to 'write' to memory layers. I'll try to add this functionality. Yup!! > However, I really don't think this should be the 'default' or > primary/sole output type. I think what I'll probably do is simply add > 'output options' to the current output file dialog, such that users > can choose memory layer (this might require some work on a more > generic vector file writer), shapefile, kml, whatever... Yes, exactly :) Nobody says it should be the only option. But about the default... well ;) > So a tool to delete vector(s)/raster(s) and associated files. > Something like a open file dialog where you can select x number of > QGIS supported vector/raster files, and delete them all in one go? > That would be handy... Yes. And also a reverse possibility: to select a few layers to save and remove everything else. Of course, for a safety, it shoud sort and filter files by a timestamp (like clearing data in Firefox). There are only few things in this world that I hate. One of them is saving to another and another and another and another file :D ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
I think overwriting an existing layer in memory is not a good practice. Updating existing geometry or attribute data would be great, such as when one merges two themes, and when the second theme is only contributing matching attribute. But overwriting should at least not be the default behavior. While using Python, I always feel it is not good that it wants to create a new even if the data I am adding is a dbf file. I think that is not helpful, there should be an option to append the data (this may apply to both the geometry and attribute) or make an new one. Thank you, Maaza --- On Mon, 3/7/11, Borys Jurgiel wrote: From: Borys Jurgiel Subject: Re: [Qgis-developer] In with the new, out with the old? To: qgis-developer@lists.osgeo.org Cc: "Chris Crook" Date: Monday, March 7, 2011, 6:31 PM Dnia poniedziałek 07 marca 2011 o 23:48:46 Carson Farmer napisał(a): > Ok, I'm getting the overwhelming feeling that people want to be able > to 'write' to memory layers. I'll try to add this functionality. Yup!! > However, I really don't think this should be the 'default' or > primary/sole output type. I think what I'll probably do is simply add > 'output options' to the current output file dialog, such that users > can choose memory layer (this might require some work on a more > generic vector file writer), shapefile, kml, whatever... Yes, exactly :) Nobody says it should be the only option. But about the default... well ;) > So a tool to delete vector(s)/raster(s) and associated files. > Something like a open file dialog where you can select x number of > QGIS supported vector/raster files, and delete them all in one go? > That would be handy... Yes. And also a reverse possibility: to select a few layers to save and remove everything else. Of course, for a safety, it shoud sort and filter files by a timestamp (like clearing data in Firefox). There are only few things in this world that I hate. One of them is saving to another and another and another and another file :D ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] 1 Mac section was skipped in r15383
Lines 806-826, still some old shortcuts->... stuff here. It won't compile. - William Kyngesburye http://www.kyngchaos.com/ "The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects." - the wisdom of Tarzan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
+1 --- Paolo Cavallini http://faunalia.it/pc - Reply message - Da: "Borys Jurgiel" A: Oggetto: [Qgis-developer] Raster providers Data: lun, mar 7, 2011 23:22 Dnia niedziela 06 marca 2011 o 21:18:59 Radim Blazek napisał(a): > Hi, > I am ready to merge raster-providers branch to trunk. Are you ready too? > > Radim Just to let you know, some of us are looking forward :-) There's less and less time for testing :) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] In with the new, out with the old?
Hi Carson: On 07/03/2011 20:38, Paolo Cavallini wrote: Il giorno lun, 07/03/2011 alle 18.16 +, Carson Farmer ha scritto: - Export/add geometry columns (this can now be done quite easily from the field calculator, and my version appears to have issues with certain vector formats) I find your solution more intuitive for newbies, and I would like to keep it, at least for now. Can calculator extract x and y from points? Quite true. - Select by location (I think there is a 'Spatial Query' plugin which has this functionality plus much more, and appears to be quite fast) Right, even though the spatial query is more complex to use. Where is this "spatial query". I updated a Win XP machine last night to the latest 1.7 with OSGeo4W setup, and I don't find any spatial query? In any case, I like your suggestion to put wrappers to all these new plugins (C++ also) under the "Vector" menu. THere's been a lot of discussion regarding consolidating plugins under categories /menu topics to make things easier to find. Any spatial query tools should, in my opinion appear under the Vector menu. In fact, the new Join Attributes option, which is now a tab in the layer properties window might also find a place under Vector. Furthermore, there's the MMQGIS set of vector tools, some of which duplicate fTools functions (i.e. merge shapefile). Perhaps an effort to organize all these tools in one place would be worthwhile. Thanks, -- Micha - Define current projection (Is this covered by the new 'Set CRS of Layer(s)' tool? I haven't had much of a play with this one yet, but it sounds like it should, and is more convenient being part of the main GUI) AFAIK, the properties define a projection at runtime, whereas your tool actually writes a prj file. Am I wrong? BTW, I think now fTools could often avoid writing new shapefiles, just adding the new info on the existing layer instead (e.g. points in polygons, etc.). Would this be hard? All the best. -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 1 Mac section was skipped in r15383
On Tue, Mar 8, 2011 at 4:55 AM, William Kyngesburye wrote: > Lines 806-826, still some old shortcuts->... stuff here. It won't compile. Hi William, r15387 should fix that. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
