[Qgis-developer] again on encoding problems
Hi all. Here in the Far East the encoding is a serious problem hampering the use of QGIS. I was just pointed out a problem with the GRASS plugin on Win: http://hub.qgis.org/issues/4547 and the solution the use: http://osgeo-org.1560.n6.nabble.com/Qgis1-5-Grass-tt3730164.html#a3730165 basically they set up the entire environment in EN, but this is not optimal, as the translation is actually there, as we can see e.g. on osx and of course on Linux. It looks a very simple problem, anybody has an idea on how to solve it more elegantly? All the best, and thanks. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] matplotlib in mac
Il 24/10/2012 13:33, Noli Sicad ha scritto: > I think Matplotib package is not install in by default in any other > system. You have to download and install it by yourself. In Win standalone it is installed. > > Anyway, you can download in Willam's site (below) and install it very > easily in Mac OS X. > > http://www.kyngchaos.com/software/python > ok, thanks a lot for this. Still, I think it should be included in the package, for the comfort of the users. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] User profiles
Il 24/10/2012 15:59, Martin Dobias ha scritto: > The browser tree dock widget is a good thing, but it cannot replace > the add layer dialog completely as it is missing some power when it > comes to provider-specific options - select ID of a postgis view, > select style of a WMS layer or open a CSV layer... Martin wouldn't it be better to add this to the browser, instead of having (one more) double solution? thanks. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] setPkgDataPath issue
Larry, I commented out the setPkgDataPath line because with that load of GdalTools plugin out of output/python/plugin path fails with this message: Traceback (most recent call last): File "/usr/src/qgis/Quantum-GIS/b/output/python/qgis/utils.py", line 188, in startPlugin plugins[packageName] = package.classFactory(iface) File "/usr/src/qgis/Quantum-GIS/python/plugins/fTools/__init__.py", line 53, in classFactory which seems to mean that the startPlugin function, loaded from output dir, finds the __init__.py file in the _source_ dir rather than finding the one in output dir. The same kind of error happens with _all_ the plugins, not only GdalTools. I understand from your commit log that something else broke without that line, can we find another way to fix it ? Can you explain what the problem was ? I don't know what "crssync" is... --strk; http://www.cartodb.com - Map, analyze and build applications with your data ~~ http://strk.keybit.net ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] User profiles
Hi,
Browser needs at least 3 improvements to get reed of an extra button:
1- ability to reorder folders and files by name or date. If sometimes have
seen mixed up folders in browser, without knowing why...
2- ability to connect ("mount") a shortcut to a location like in Arcmap.
This is because data can be stored in very long folders tree, to large for
browser panel. Navigation becomes quickly uncomfortable.
Thoughts ?
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/User-profiles-tp5010487p5010723.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] setPkgDataPath issue
Hi strk, On Wed, Oct 24, 2012 at 1:22 AM, Sandro Santilli wrote: > Larry, I commented out the setPkgDataPath line because with > that load of GdalTools plugin out of output/python/plugin path > fails with this message: > > Traceback (most recent call last): >File "/usr/src/qgis/Quantum-GIS/b/output/python/qgis/utils.py", line 188, > in startPlugin > plugins[packageName] = package.classFactory(iface) >File "/usr/src/qgis/Quantum-GIS/python/plugins/fTools/__init__.py", line > 53, in classFactory > > which seems to mean that the startPlugin function, loaded from output dir, > finds the __init__.py file in the _source_ dir rather than finding the one > in output dir. > > The same kind of error happens with _all_ the plugins, not only GdalTools. In addition to what we discussed on irc, i.e. why that setPkgDataPath call should stay as is, it sounds more like an issue with sys.path. If the interpreter is finding modules in the source directory before output, maybe prepend the staged output dir to sys.path, so it is always searched before the source dir. Larry > I understand from your commit log that something else broke without that line, > can we find another way to fix it ? Can you explain what the problem was ? > I don't know what "crssync" is... > > --strk; > > http://www.cartodb.com - Map, analyze and build applications with your data > >~~ http://strk.keybit.net > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
On Tue, Oct 23, 2012 at 10:58 PM, Pirmin Kalberer wrote: > Hi Martin, > > Am Montag, 22. Oktober 2012, 21.17:20 schrieb Martin Dobias: >> >> recently I have been brewing some backwards incompatible API changes >> that will 1) enable introduction of threading, 2) simplify API for >> developers. I would like to merge the changes soon to master branch in >> order not to drift too much from master. > > -1 from me. > This is against the release plan we agreed on the hackfest. > > IMHO, current master can be a great 2.0 release with many new features in a > few months. > Your additions are the begin of the next level - an even greater 3.0 release. So what was the conclusion about threading? I had to leave HF during the discussion but my impression was that threading was marked as important and it should go to 2.0. If Martin is finally willing to merge threading we should support him. The threading branch (the knowledge) could also be lost during the years until the 3.0 release. Is there the 2.0 changes list written on flip chart on HF somewhere on wiki? If not, I'll start one. Is there a photo? Radim > So I would strongly prefer to have these changes in a "plugin-ng"-branch > instead of starting a "frozen" 1.9 branch. > > Regards > 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] setPkgDataPath issue
On Wed, Oct 24, 2012 at 02:14:46AM -0600, Larry Shaffer wrote: > Hi strk, > > On Wed, Oct 24, 2012 at 1:22 AM, Sandro Santilli wrote: > > Larry, I commented out the setPkgDataPath line because with > > that load of GdalTools plugin out of output/python/plugin path > > fails with this message: > > > > Traceback (most recent call last): > >File "/usr/src/qgis/Quantum-GIS/b/output/python/qgis/utils.py", line > > 188, in startPlugin > > plugins[packageName] = package.classFactory(iface) > >File "/usr/src/qgis/Quantum-GIS/python/plugins/fTools/__init__.py", line > > 53, in classFactory > > > > which seems to mean that the startPlugin function, loaded from output dir, > > finds the __init__.py file in the _source_ dir rather than finding the one > > in output dir. > > > > The same kind of error happens with _all_ the plugins, not only GdalTools. > > In addition to what we discussed on irc, i.e. why that setPkgDataPath > call should stay as is, it sounds more like an issue with sys.path. If > the interpreter is finding modules in the source directory before > output, maybe prepend the staged output dir to sys.path, so it is > always searched before the source dir. I checked sys.path and it does NOT contain the source dir at all. Did you try to load python plugins from output/bin/qgis ? With and without the setPkgDataPath ? Because with the call they don't load, without they load. The same applies with the console, too: https://github.com/qgis/Quantum-GIS/pull/299 --strk; http://www.cartodb.com - Map, analyze and build applications with your data ~~ http://strk.keybit.net ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] setPkgDataPath issue
Also, Larry, not everyone is on IRC, could you explain here again why setPkgDataPath is needed ? --strk; On Wed, Oct 24, 2012 at 10:28:54AM +0200, Sandro Santilli wrote: > On Wed, Oct 24, 2012 at 02:14:46AM -0600, Larry Shaffer wrote: > > Hi strk, > > > > On Wed, Oct 24, 2012 at 1:22 AM, Sandro Santilli wrote: > > > Larry, I commented out the setPkgDataPath line because with > > > that load of GdalTools plugin out of output/python/plugin path > > > fails with this message: > > > > > > Traceback (most recent call last): > > >File "/usr/src/qgis/Quantum-GIS/b/output/python/qgis/utils.py", line > > > 188, in startPlugin > > > plugins[packageName] = package.classFactory(iface) > > >File "/usr/src/qgis/Quantum-GIS/python/plugins/fTools/__init__.py", > > > line 53, in classFactory > > > > > > which seems to mean that the startPlugin function, loaded from output dir, > > > finds the __init__.py file in the _source_ dir rather than finding the one > > > in output dir. > > > > > > The same kind of error happens with _all_ the plugins, not only GdalTools. > > > > In addition to what we discussed on irc, i.e. why that setPkgDataPath > > call should stay as is, it sounds more like an issue with sys.path. If > > the interpreter is finding modules in the source directory before > > output, maybe prepend the staged output dir to sys.path, so it is > > always searched before the source dir. > > I checked sys.path and it does NOT contain the source dir at all. > > Did you try to load python plugins from output/bin/qgis ? > With and without the setPkgDataPath ? > Because with the call they don't load, without they load. > > The same applies with the console, too: > https://github.com/qgis/Quantum-GIS/pull/299 > > --strk; > > http://www.cartodb.com - Map, analyze and build applications with your data > >~~ http://strk.keybit.net > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] User profiles
> 2- ability to connect ("mount") a shortcut to a location like in Arcmap.
is available through favorites.
In browser, we cannot choose the encoding of e.g. Shapefiles. At least
when opened directly from Zip, German Umlaute are always messed up.
Best wishes,
Anita
On Wed, Oct 24, 2012 at 9:58 AM, haubourg
wrote:
> Hi,
> Browser needs at least 3 improvements to get reed of an extra button:
> 1- ability to reorder folders and files by name or date. If sometimes have
> seen mixed up folders in browser, without knowing why...
> 2- ability to connect ("mount") a shortcut to a location like in Arcmap.
> This is because data can be stored in very long folders tree, to large for
> browser panel. Navigation becomes quickly uncomfortable.
> Thoughts ?
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/User-profiles-tp5010487p5010723.html
> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> ___
> 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] User profiles
On Wed, Oct 24, 2012 at 5:25 PM, Paolo Cavallini wrote: > wouldn't it be better to add this to the browser, instead of having (one > more) double solution? While it sounds like a good idea I think the browser falls short on a few usability issues that I think having a separate diolog for would resolve. - No sorting (how would you sort a tree of items?) - expanding a item with a large count of subitems now means I have to scroll up and down to find other folders/connections - Limited room in the UI - Tree views become a pain to use if they become to large I like the browser dock as a quick shortcut to load layers but I don't think it should replace a good open layer dialog. The open layer dialog that I did a mockup of does use a tree view but it's only for the top level items like connections and the layers are shown in the right hand side. - Nathan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
2012/10/24 Radim Blazek : > Is there the 2.0 changes list written on flip chart on HF somewhere on > wiki? If not, I'll start one. Is there a photo? As I can see from this photo [0] threading included to 2.0 roadmap but marked as non-blocker [0] https://plus.google.com/u/0/events/ct98c2u7js7hjj842sihlbcrqpo/101650015976513787909/5796119152216619122?gpinv=AMIXal9C5Tt4fMyTp5aYiWiZ6MGahRTLPt5h6c4yenOXjeoHvm5MfOEeqVmj1cGQQDH4TrW9GYgzGqF87v4B2y__nzvM5NrPZM4GuMwKzQP47DnF6nQK_rc -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] again on encoding problems
Hello Paolo, I haven't seen how QGIS GRASS plug in is built, still my 0.02 from GRASS side. Some time a go I investigated encoding problems in native GRASS on Windows (WinGRASS) and my conclusion was - it is not possible to fix it for GRASS 6 due to character encoding handling in Windows. Reason was simple - there's no single coding to cover all use cases in Windows (CLI has one system (OEM), GUI has it's legacy system (ANSI) and add to all also Unicode in more recent code). As GRASS strings might come in all three encodings, unless the source of string is known, it's impossible to convert/display string correctly. Somebody with greater QGIS part can correct me, if I'm wrong (as I would like to be :) ). Maris. PS. http://lists.osgeo.org/pipermail/grass-dev/2011-March/053874.html 2012/10/24 Paolo Cavallini : > Hi all. > Here in the Far East the encoding is a serious problem hampering the use > of QGIS. > I was just pointed out a problem with the GRASS plugin on Win: > http://hub.qgis.org/issues/4547 > and the solution the use: > http://osgeo-org.1560.n6.nabble.com/Qgis1-5-Grass-tt3730164.html#a3730165 > basically they set up the entire environment in EN, but this is not > optimal, as the translation is actually there, as we can see e.g. on osx > and of course on Linux. > It looks a very simple problem, anybody has an idea on how to solve it > more elegantly? > All the best, and thanks. > > -- > Paolo Cavallini - Faunalia > www.faunalia.eu > Full contact details at www.faunalia.eu/pc > Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario > > ___ > 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] User profiles
Sorry! didn't see that.. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/User-profiles-tp5010487p5010765.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
Hi! Probably I missed something in Essen but to my knowledge it was always clear that 2.0 will have _a lot of API Changes_ .. And I missed them already. So now someone (Martin) is starting to bring us to a point where a 2.0 really earns its big number change. I am really looking forward to have threading (and a lot of other things that makes the 2 a real 2) included. For the "frozen" release .. well .. What about keeping the last "nightly" version before martins changes as a package on the page? - Will not change anything about the current situation and will keep people able to do their work (personally I do not expect that Martin's changes will break whole QGIS and I also expect that the most important and used plugins will get adjusted soon). Waiting for a 3.0 is probably way too long for such important changes and Martin would have to do his work a third time again .. As I already know the great community around the project - I am sure we will manage it somehow to keep the release straight.. with an even greater, faster and better QGIS 2.0. What about an real Roadmap? And a more or less aimed date to release 2.0? Is there already anything like that? I think that would probably focus the aim kind regards Werner On Wed, Oct 24, 2012 at 11:04 AM, Alexander Bruy wrote: > 2012/10/24 Radim Blazek : >> Is there the 2.0 changes list written on flip chart on HF somewhere on >> wiki? If not, I'll start one. Is there a photo? > As I can see from this photo [0] threading included to 2.0 roadmap but marked > as non-blocker > > [0] > https://plus.google.com/u/0/events/ct98c2u7js7hjj842sihlbcrqpo/101650015976513787909/5796119152216619122?gpinv=AMIXal9C5Tt4fMyTp5aYiWiZ6MGahRTLPt5h6c4yenOXjeoHvm5MfOEeqVmj1cGQQDH4TrW9GYgzGqF87v4B2y__nzvM5NrPZM4GuMwKzQP47DnF6nQK_rc > > > -- > Alexander Bruy > ___ > 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] Merging of incompatible changes
There is also something else to remember here. These changes that Martin is proposing to merge are not the threading changes, it is the API to allow threading to be added later. Even without threading being added the API update is worth it. Having a cleaner API is always a good thing. Cleaner APIs == Happy developers - Nathan On Wed, Oct 24, 2012 at 9:46 PM, Werner Macho wrote: > Hi! > > Probably I missed something in Essen but to my knowledge it was always > clear that 2.0 will have _a lot of API Changes_ .. And I missed them > already. So now someone (Martin) is starting to bring us to a point > where a 2.0 really earns its big number change. > I am really looking forward to have threading (and a lot of other > things that makes the 2 a real 2) included. > > For the "frozen" release .. well .. What about keeping the last > "nightly" version before martins changes as a package on the page? - > Will not change anything about the current situation and will keep > people able to do their work (personally I do not expect that Martin's > changes will break whole QGIS and I also expect that the most > important and used plugins will get adjusted soon). > Waiting for a 3.0 is probably way too long for such important changes > and Martin would have to do his work a third time again .. > > As I already know the great community around the project - I am sure > we will manage it somehow to keep the release straight.. with an even > greater, faster and better QGIS 2.0. > What about an real Roadmap? And a more or less aimed date to release > 2.0? Is there already anything like that? I think that would probably > focus the aim > > kind regards > Werner > > > On Wed, Oct 24, 2012 at 11:04 AM, Alexander Bruy > wrote: >> 2012/10/24 Radim Blazek : >>> Is there the 2.0 changes list written on flip chart on HF somewhere on >>> wiki? If not, I'll start one. Is there a photo? >> As I can see from this photo [0] threading included to 2.0 roadmap but marked >> as non-blocker >> >> [0] >> https://plus.google.com/u/0/events/ct98c2u7js7hjj842sihlbcrqpo/101650015976513787909/5796119152216619122?gpinv=AMIXal9C5Tt4fMyTp5aYiWiZ6MGahRTLPt5h6c4yenOXjeoHvm5MfOEeqVmj1cGQQDH4TrW9GYgzGqF87v4B2y__nzvM5NrPZM4GuMwKzQP47DnF6nQK_rc >> >> >> -- >> Alexander Bruy >> ___ >> 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 mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] User profiles
Hi! my 2¢ regarding profile. I personally find the Interface crowded with far too many icons. The big problem I see is that for every person working with QGIS other icons(functions) are important to have directly clickable available. That leads me to the question I shortly discussed with Tim at the Hackfest in Essen. What about providing only basic functions to the user (Like I assume it was meant by Martin) AND provide some kind of "create your own toolbars". I think it's overhead to give an iconspace on the mainscreen to every plugin you install which leads to more space crowded by icons than real "workspace". Keep it simple and let the user easily choose his own (one ore more) toolbars. Probably some kind of question while installing a plugin would be "Would you like to add an icon for this plugin to the main workspace?" and then poping up the (to be created) "toolbar adding" tool. I hope my explanation is not too complicated and you all know what I mean. I think that would save a lot of space (adding new functions _only_ to menu and not automatically adding a icon to the screen) and let the User choose. kind regards Werner ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
On 23/10/2012 09:28, Sandro Santilli wrote: On Mon, Oct 22, 2012 at 09:35:05PM +0200, Werner Macho wrote: Hi! Short answer from me +1 and go ahead .. As I remember we all knew that on the way to 2.0 there will be some API Changes - but as long as it improves QGIS at a Project I see no Problem for it .. The only thing you are worrying about are the Plugins .. but hey - there is still 1.8 .. Assuming it's going to be maintained... As I'm not a developer, I can only gently mention my wishes: Back when the 1.7.x version was the "stable" a lot of good effort was put into implementing bug fixes, eventually leading to an excellent 1.7.4. I hope now, with 2.0 bringing these API changes and breaking plugins etc, that a 1.8.x stable will be maintained "for the duration" until the new version settles, and plugin developers can catchup. Thanks, Micha And once all those changes settled in (upcoming) 2.0 - from my point of view it would be time for a new release .. Probably we should introduce a max.Version to plugins too? ;) I think all changes should be made backward compatible unless the development cost in doing so is higher than the development cost of upgrading all plugins. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer This mail was received via Mail-SeCure System. -- Micha Silver 052-3665918 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
Hi All, As Martin asked, could we know more about 2.0 roadmap planning and feature list? My concern is that we deployed QGIS in prod for 300 users, but we still miss some bugfixes and features to definitly switch. As long as I maintain two GIS solutions, I have double work, and I can't dedicate more time to QGIS. I would like to support prioritary issues before feature freeze. In the other hand, I can't wait until end of 2013 to fix 1.8 issues (raster print KO.. for example). We also just supported, with others of you, great tools like Atlas.. If a stable version with it is not released within a year, users will start to get annoyed, and will tend to use master for production use.. which is not a good target for any of us. So what is the community plan? What should we do as users and sponsors? Should we ask (and support) a 1.8 bugfix release if 2.0 target moves again? Should we support a 1.9 release for 2013 spring, and let major API changes for 2.0 be planned to end of 2013? Does community have enough ressources to release a 1.9? Please tell us, we love QGIS and its community.. but we also like very much stability and visibility (and the captive users in my corp' too) Régis -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Merging-of-incompatible-changes-tp5010325p5010839.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
Hi Pirmin and others, Tim should correct me - but as far as I remember we said that threading support is one of the major things we want to see in QGIS 2.0 (along with raster redesign, atlas printing and others). But none of us were sure in what timeframe Martin can work on it and when it will be finished. Therefore we decided not to make it a blocker. We also decided that the geometry refactoring (for arcs, splines, z-values, m-values, multitype geometries, etc.) should be done after QGIS 2.0. I am not sure if this would again mean API breaks ... So I am against postponing the multithreading work and I had the impression that this was the conclusion of others as well. Andreas On Tue, 23 Oct 2012 22:58:25 +0200, Pirmin Kalberer wrote: Hi Martin, Am Montag, 22. Oktober 2012, 21.17:20 schrieb Martin Dobias: recently I have been brewing some backwards incompatible API changes that will 1) enable introduction of threading, 2) simplify API for developers. I would like to merge the changes soon to master branch in order not to drift too much from master. -1 from me. This is against the release plan we agreed on the hackfest. IMHO, current master can be a great 2.0 release with many new features in a few months. Your additions are the begin of the next level - an even greater 3.0 release. So I would strongly prefer to have these changes in a "plugin-ng"-branch instead of starting a "frozen" 1.9 branch. Regards Pirmin -- -- 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] matplotlib in mac
On Oct 24, 2012, at 2:23 AM, Paolo Cavallini wrote: > Il 24/10/2012 13:33, Noli Sicad ha scritto: >> I think Matplotib package is not install in by default in any other >> system. You have to download and install it by yourself. > In Win standalone it is installed. >> >> Anyway, you can download in Willam's site (below) and install it very >> easily in Mac OS X. >> >> http://www.kyngchaos.com/software/python >> > ok, thanks a lot for this. Still, I think it should be included in the > package, for the comfort of the users. > All the best. Well, my own reasoning is mostly that I don't like lots of duplication, it just bloats packages for a small convenience. QGIS package is 75MiB, Matplotlib is 53MiB. I don't do a standalone package any more because there were problems (although now fixed I think) and of all the shared parts (GDAL, SQlite, python stuff, ...) are useful on their own (but only useful to QGIS in a standalone) and to other packages like GRASS, MapServer and PostGIS. Also, when QGIS 1.8 was released, certain plugins were not rewritten to use it yet. - William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] User profiles
My 2 cents. I agree with all of you about the need to remove some default toolbars. Following the proposal of Werner, what about having a "View" menu, where the user can choose which toolbars activate and not? And as an improvement to this, one could provide a system to "Add custom buttons" to the toolbar space. Giovanni 2012/10/24 Werner Macho > Hi! > > my 2¢ regarding profile. > > I personally find the Interface crowded with far too many icons. The > big problem I see is that for every person working with QGIS other > icons(functions) are important to have directly clickable available. > That leads me to the question I shortly discussed with Tim at the > Hackfest in Essen. > > What about providing only basic functions to the user (Like I assume > it was meant by Martin) AND provide some kind of "create your own > toolbars". I think it's overhead to give an iconspace on the > mainscreen to every plugin you install which leads to more space > crowded by icons than real "workspace". Keep it simple and let the > user easily choose his own (one ore more) toolbars. > Probably some kind of question while installing a plugin would be > "Would you like to add an icon for this plugin to the main workspace?" > and then poping up the (to be created) "toolbar adding" tool. > I hope my explanation is not too complicated and you all know what I mean. > I think that would save a lot of space (adding new functions _only_ to > menu and not automatically adding a icon to the screen) and let the > User choose. > > kind regards > Werner > ___ > 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] User profiles
2012/10/24 Alexander Bruy : > 2012/10/24 G. Allegri : >> My 2 cents. >> I agree with all of you about the need to remove some default toolbars. >> Following the proposal of Werner, what about having a "View" menu, where the >> user can choose which toolbars activate and not? > > Already here. Look at "View - Panels" and "View - Toolbars" menus > >> And as an improvement to >> this, one could provide a system to "Add custom buttons" to the toolbar >> space. > > Custom toolbars will be great improvement > > -- > Alexander Bruy -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] User profiles
I knew that toolbars are already able to be switched on and off.. My intention was to create those custom toolbars because currently you can switch whole bars on and off.. But what if I use only one tool from a huge bar?.. So I tend to keep the default small.. And create my own toolbar.. Regards Werner Am 24.10.2012 18:18 schrieb "Alexander Bruy" : > 2012/10/24 Alexander Bruy : > > 2012/10/24 G. Allegri : > >> My 2 cents. > >> I agree with all of you about the need to remove some default toolbars. > >> Following the proposal of Werner, what about having a "View" menu, > where the > >> user can choose which toolbars activate and not? > > > > Already here. Look at "View - Panels" and "View - Toolbars" menus > > > >> And as an improvement to > >> this, one could provide a system to "Add custom buttons" to the toolbar > >> space. > > > > Custom toolbars will be great improvement > > > > -- > > Alexander Bruy > > > > -- > Alexander Bruy > ___ > 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] User profiles
Yes, I meant custom toolboars and single custom buttons... 2012/10/24 Werner Macho > I knew that toolbars are already able to be switched on and off.. My > intention was to create those custom toolbars because currently you can > switch whole bars on and off.. But what if I use only one tool from a huge > bar?.. > So I tend to keep the default small.. And create my own toolbar.. > Regards > Werner > Am 24.10.2012 18:18 schrieb "Alexander Bruy" : > > 2012/10/24 Alexander Bruy : >> > 2012/10/24 G. Allegri : >> >> My 2 cents. >> >> I agree with all of you about the need to remove some default toolbars. >> >> Following the proposal of Werner, what about having a "View" menu, >> where the >> >> user can choose which toolbars activate and not? >> > >> > Already here. Look at "View - Panels" and "View - Toolbars" menus >> > >> >> And as an improvement to >> >> this, one could provide a system to "Add custom buttons" to the toolbar >> >> space. >> > >> > Custom toolbars will be great improvement >> > >> > -- >> > Alexander Bruy >> >> >> >> -- >> Alexander Bruy >> ___ >> 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 mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] GIT authentication problem on qgis.org
I cannot get GIT on qgis.org working. I added my public key in http://hub.qgis.org/my/public_keys, I am developer in http://hub.qgis.org/projects/valuetool but I am always asked for password: git clone gito...@qgis.org:valuetool.git valuetool Cloning into valuetool... gito...@qgis.org's password: I have read all the email about this problems but cannot find solution. Is it supposed to work? Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Invert color ramp not working?
On Fri, Oct 19, 2012 at 9:52 PM, Paolo Cavallini wrote: > Hi all. > In a recent master, raster properties, if I check the flag "invert color > ramp", I do not get the expected result, but the old ugly red-blue ramp: Invert color was missing in pseudocolor renderer, fixed. The question is what is it expected to do. I have used red = 255 - red; green = 255 - green; blue = 255 - blue; which is used for multiband color (both master and 1.8) but in 1.8 pseudocolor red and blue were switched instead. You are probably expecting the classification to be done in reverse order? I think that invert color has little/no sense for pseudocolor and multiband color as it is implemented in master or/and was in 1.8. For pseudo color it should be moved to "Generate new color map" options, for multiband color just removed. In any case, legend is not correct if invert color is used. Radim > anyone confirms? > Thanks. > > -- > Paolo Cavallini - Faunalia > www.faunalia.eu > Full contact details at www.faunalia.eu/pc > Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario > > ___ > 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] Merging of incompatible changes
Hi defs Yes, the decision was that multithreading branch should be in 2.0. Personally, I'm in favor of merging it as soon as possible (to give the dev team enough time to get used to the new classes and to handle possible side effects). Martin, is your planned merge already the full threading branch merge or a part of it? Pathon changes: I don't have a strong opinion here, but most people on the list seem to be in favor of them ( they are not afraid to adapt their plugins for 2.0). >We also decided that the geometry refactoring (for arcs, splines, z-values, m-values, multitype >geometries, etc.) should be done after QGIS 2.0. I am not sure if this would again mean API breaks ... I think that can wait until version 3... Regards, Marco On 24.10.2012 16:13, Andreas Neumann wrote: Hi Pirmin and others, Tim should correct me - but as far as I remember we said that threading support is one of the major things we want to see in QGIS 2.0 (along with raster redesign, atlas printing and others). But none of us were sure in what timeframe Martin can work on it and when it will be finished. Therefore we decided not to make it a blocker. We also decided that the geometry refactoring (for arcs, splines, z-values, m-values, multitype geometries, etc.) should be done after QGIS 2.0. I am not sure if this would again mean API breaks ... So I am against postponing the multithreading work and I had the impression that this was the conclusion of others as well. Andreas On Tue, 23 Oct 2012 22:58:25 +0200, Pirmin Kalberer wrote: Hi Martin, Am Montag, 22. Oktober 2012, 21.17:20 schrieb Martin Dobias: recently I have been brewing some backwards incompatible API changes that will 1) enable introduction of threading, 2) simplify API for developers. I would like to merge the changes soon to master branch in order not to drift too much from master. -1 from me. This is against the release plan we agreed on the hackfest. IMHO, current master can be a great 2.0 release with many new features in a few months. Your additions are the begin of the next level - an even greater 3.0 release. So I would strongly prefer to have these changes in a "plugin-ng"-branch instead of starting a "frozen" 1.9 branch. Regards Pirmin -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Weberstrasse 5, CH-8004 Zürich, 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] Merging of incompatible changes
Hi Martin, Andreas and others, Am Mittwoch, 24. Oktober 2012, 16.13:34 schrieb Andreas Neumann: > > Tim should correct me - but as far as I remember we said that threading > support is one of the major things we want to see in QGIS 2.0 (along > with raster redesign, atlas printing and others). But none of us were > sure in what timeframe Martin can work on it and when it will be > finished. Therefore we decided not to make it a blocker. > > We also decided that the geometry refactoring (for arcs, splines, > z-values, m-values, multitype geometries, etc.) should be done after > QGIS 2.0. I am not sure if this would again mean API breaks ... > > So I am against postponing the multithreading work and I had the > impression that this was the conclusion of others as well. I'm waiting for Tim dropping into the discussion as well... In Essen, we decided against integrating major new features (like multithreading) into the next release. We did decide filling the missing gaps to fully replace old symbology and old labelling (Paolo: Kickstarter pledge on the way?) and polishing the many new features already integrated. We already have some API breaks. I've spent quite some time in Essen to get a full list of it: http://hub.qgis.org/wiki/quantum-gis/API_changes_for_version_20#Full-diff My estimation is, that about 1% of all existing plugins are affected by the API changes in the current master branch. So we're talking of about 2 of 160 plugins in the central repo and maybe 160 of 16'000 unpublished user plugins (any better estimation than 1:100 between published and unpublished plugins?). Martins proposed API change means we break 160 of 160 and 16'000 of 16'000 plugins. It will take years to bring them all in sync with QGIS again. And we're not only talking about plugins. We're talking about a possible 2.0 release with WMTS, WFS-T, huge raster improvements including performance factor 4 with PNG/8, Atlas printing, Sextante and minor things like fixed Shapefile support in Q1/2013. The other option is a new QGIS with release date far in 2014 and a giant gap between users working with QGIS 1.7.4, 1.8++ and developers working on a new QGIS and releasing plugins in a separate repository. Companies like ours will get paid for maintaining branches for customers who need stable and compatible releases. There will be 1.8 custom branches with backported fixes/features and a garanteed non-frozen 1.9 branch. I will remind Marco in 2014 of his +1 when he's still compiling QGIS 1.8 and investing a lot of time backporting fixes to a single-threaded version. I would very much prefer let him work on *new* features, which are a profit for *all* users, like in recent years. We are on a developer list here. As a developer I like the proposed changes very much. QGIS is made by developers, but is also made for users. And sometimes we should care about users - even the 99% Windows users. That's why I'm voting for a polished 2.0 release in a few month with the great feature set we already have. Regards 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] Merging of incompatible changes
Hi Pirmin On Wed, Oct 24, 2012 at 10:39 PM, Pirmin Kalberer wrote: > > We already have some API breaks. I've spent quite some time in Essen to get a > full list of it: > http://hub.qgis.org/wiki/quantum-gis/API_changes_for_version_20#Full-diff > My estimation is, that about 1% of all existing plugins are affected by the > API changes in the current master branch. So we're talking of about 2 of 160 > plugins in the central repo and maybe 160 of 16'000 unpublished user plugins > (any better estimation than 1:100 between published and unpublished plugins?). > Martins proposed API change means we break 160 of 160 and 16'000 of 16'000 > plugins. It will take years to bring them all in sync with QGIS again. I would be more conservative with such estimates, maybe 500 plugins altogether? But that's not really important for the discussion. > And we're not only talking about plugins. We're talking about a possible 2.0 > release with WMTS, WFS-T, huge raster improvements including performance > factor 4 with PNG/8, Atlas printing, Sextante and minor things like fixed > Shapefile support in Q1/2013. The other option is a new QGIS with release date > far in 2014 and a giant gap between users working with QGIS 1.7.4, 1.8++ and > developers working on a new QGIS and releasing plugins in a separate > repository. Companies like ours will get paid for maintaining branches for > customers who need stable and compatible releases. There will be 1.8 custom > branches with backported fixes/features and a garanteed non-frozen 1.9 branch. > I will remind Marco in 2014 of his +1 when he's still compiling QGIS 1.8 and > investing a lot of time backporting fixes to a single-threaded version. I > would very much prefer let him work on *new* features, which are a profit for > *all* users, like in recent years. I understand your concerns - but I can imagine that if the API changes are postponed to QGIS 3.0, in three years there will be five times more plugins and therefore several times more code that would need updating. So will we again shift the changes to QGIS 4.0 in order to not break them? My point is that there will be always push from users not to break anything - and we need to decide at some point to do the necessary cleanup and do not postpone it forever. What about other changes, like removal of old symbology and old labeling? Those will also break many plugins... Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
On Wed, Oct 24, 2012 at 10:38 PM, Marco Hugentobler wrote: > Hi defs > > Yes, the decision was that multithreading branch should be in 2.0. > Personally, I'm in favor of merging it as soon as possible (to give the dev > team enough time to get used to the new classes and to handle possible side > effects). Martin, is your planned merge already the full threading branch > merge or a part of it? Hi Marco First I would like to merge API changes that are required in order to get threaded rendering in place. I am trying to write unit tests so hopefully there won't be many regressions. After that I will be reintroducing threaded rendering. In case that we would find out that threaded rendering is not ready for prime time, it should be easy to disable it in order not to wait with 2.0 release just for it... so we should be still able to ship 2.0 sometime in spring/summer 2013 with or without threading. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
Il 25/10/2012 05:39, Pirmin Kalberer ha scritto: > We did decide filling the missing gaps to fully replace old > symbology and old labelling (Paolo: Kickstarter pledge on the way?) and > polishing the many new features already integrated. Sorry, no progress on this. I've asked for some feedback and help, got none. Very little time now, planning to do it ASAP. Any help welcome. > plugins. It will take years to bring them all in sync with QGIS again. I understand both Pirmin and Martin concerns. I think seriously breaking the API and all the plugins will be good *if* we have a serious plan on how to migrate the plugins. At this stage, we cannot afford releasing a 2.0 without plugins, as nobody will use it, and we'll get stuck in the middle of the transition. This had proved to be a major problem for many software, sometimes effectively killing it, and we should really seriously avoid them. I think it is realistic, on the basis of the response to the request to move plugins to the new infrastructure, to assume that many developers will not do the migration in time: are we willing and capable of upgrading them ourselves, or do we plan to leave them as such? > We are on a developer list here. As a developer I like the proposed changes > very much. QGIS is made by developers, but is also made for users. And > sometimes we should care about users - even the 99% Windows users. That's why > I'm voting for a polished 2.0 release in a few month with the great feature > set we already have. +1: let's release ASAP. Please note that, as said in Essen, we can start preparing for a 3.0 release as soon as 2.0 is out, no need to wait years for that. One side note: current stable version is basically unusable as a default for all double-byte-characters people (> half of the world population). The needed change is trivial, a new release could fix this easily. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] matplotlib in mac
Il 24/10/2012 23:14, William Kyngesburye ha scritto: > > Well, my own reasoning is mostly that I don't like lots of duplication, it > just bloats packages for a small convenience. QGIS package is 75MiB, > Matplotlib is 53MiB. I don't oh! I could not imagine - python-matplotlib installed size on Debian is 9223 k. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Invert color ramp not working?
Il 25/10/2012 02:52, Radim Blazek ha scritto: > You are probably expecting the classification to be done in reverse order? Yes. > > I think that invert color has little/no sense for pseudocolor and > multiband color as it is implemented in master or/and was in 1.8. For > pseudo color it should be moved to "Generate new color map" options, > for multiband color just removed. seems good. can we disable the invert for multibands? > > In any case, legend is not correct if invert color is used. I believe this should be fixed anyway. Thanks a lot. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] User profiles
Il 24/10/2012 09:46, pcr...@pcreso.com ha scritto: > > > > So I think the idea of selectable profiles to enable a simple default > & add (unhide) capability when you are ready for it is a good idea. > Going beyond the existing selectable menus, to a list of user levels, > rather than explicit functionality. > +1 -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] User profiles
Il 24/10/2012 17:32, Anita Graser ha scritto:
>> 2- ability to connect ("mount") a shortcut to a location like in Arcmap.
> is available through favorites.
>
> In browser, we cannot choose the encoding of e.g. Shapefiles. At least
> when opened directly from Zip, German Umlaute are always messed up.
>
could you please add the list of missing functions somewhere, on a wiki
page or on a ticket?
thanks.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
In the region I'm working in (Southeast Asia), QuantumGIS' adoption rate is quickly rising, in big part due to fact that ArcGIS doesn't properly support UTF-8. Keeping these new adopters passionate about QGIS - as well as increasing user base - with an healthy release cycle is IMO really important. There are so many good new features that have been pushing into 1.9, kind of hurts to think it won't be available to a larger crowd until mid 2013. One way forward would be to put official 2.0 milestones out. For e.g., before merging the threading work, it might be good to release a QGIS 2.0 beta 1 to the public. There are net advantages in doing so: - Prevents long period of inactivity in-between official release for those who do not want to work with nightly builds - By making a more accessible development build (i.e. more people will download a standalone "beta" installer than a nightly build), you'll get more feedback and users testing the code - Easing pressure of releasing a new QGIS version, giving more time for dev plans QGIS would go from two to three flavors: i) official version, ii) beta version, iii) day-to-day dev build. Math On Wed, Oct 24, 2012 at 8:52 PM, haubourg < regis.haubo...@eau-adour-garonne.fr> wrote: > Hi All, > As Martin asked, could we know more about 2.0 roadmap planning and feature > list? > My concern is that we deployed QGIS in prod for 300 users, but we still > miss > some bugfixes and features to definitly switch. As long as I maintain two > GIS solutions, I have double work, and I can't dedicate more time to QGIS. > I would like to support prioritary issues before feature freeze. In the > other hand, I can't wait until end of 2013 to fix 1.8 issues (raster print > KO.. for example). We also just supported, with others of you, great tools > like Atlas.. If a stable version with it is not released within a year, > users will start to get annoyed, and will tend to use master for production > use.. which is not a good target for any of us. > > So what is the community plan? > What should we do as users and sponsors? Should we ask (and support) a 1.8 > bugfix release if 2.0 target moves again? Should we support a 1.9 release > for 2013 spring, and let major API changes for 2.0 be planned to end of > 2013? Does community have enough ressources to release a 1.9? > > Please tell us, we love QGIS and its community.. but we also like very much > stability and visibility (and the captive users in my corp' too) > Régis > > > > > > -- > View this message in context: > http://osgeo-org.1560.n6.nabble.com/Merging-of-incompatible-changes-tp5010325p5010839.html > Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. > ___ > 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] User profiles
> Date: Wed, 24 Oct 2012 09:56:47 +0700 > From: Marco Bernasocchi > To: qgis-developer@lists.osgeo.org > Subject: Re: [Qgis-developer] User profiles > Message-ID: <508758ef.4030...@bernawebdesign.ch> > Content-Type: text/plain; charset=ISO-8859-1 > > On 10/24/2012 09:53 AM, Alister Hood wrote: > > Hi guys, > > > >> Date: Tue, 23 Oct 2012 18:43:50 +0200 > >> From: Martin Dobias > >> To: Paolo Cavallini > >> Cc: qgis-developer > >> Subject: Re: [Qgis-developer] User profiles > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=ISO-8859-1 > >> > >> Hi Paolo > >> > >> On Tue, Oct 23, 2012 at 2:56 PM, Paolo Cavallini > >> wrote: > >>> Hi all. > >>> The discussion of this evening brought a nice idea: since we have many > >>> different types of users, whi not having a "first usage wizard" that > >>> simply asks the user which profile (s)he prefers, and then starts QGIS > >>> with only the needed menus and buttons activated? The profiles can be > >>> easily produced via the customization menu, so this seems trivial to > >>> implement, and can greatly help first-time users and special interest > >>> groups. > >>> Of course we have to have a prominent menu to re-run the wizard, and > >>> change the choice. > >>> Opinions? > >> > >> I am just afraid that with such profiles the users may forget after a > >> while they have chosen a "first-time user" profile that disables a lot > >> of functionality and then users will ask/complain about missing > >> features...? > > > > Yes, I can see why you might want to offer some default "profiles" to > > control which toolbars and panels are visible, but I don't think it is a > > good idea to use the customisation feature to hide any functionality. > > > can you elaborate on why? Here is my train of thought: If there was a system of different profiles, I imagine they should be task oriented, e.g. "raster analysis" or "hydrological modelling" (rather than "view", "edit" and "analyse" or "beginner", "expert" and "master of the known universe"). If the profiles used the "customisation" mechanism, they would not just control which toolbars and panels are on or off by default, they would control which toolbars are actually visible in the right-click menu and able to be turned on or off there. As well as hiding toolbars and panels, it is natural that specific menu entries and toolbar buttons would be hidden in each profile, and when a user needed a specific feature they would need to switch through several profiles looking to see if it existed, or alternatively look for it in the customisation dialog and enable it there (which would kind of defeat the purpose of the profiles). Essentially the hidden features would be a lot less discoverable. How would the default profiles work with user customisations (including the user simply turning a toolbar on or off)? When a user switches to a different profile, would their own customisations be automatically saved to the first profile? Would they be prompted to save the changes to a new custom profile? Is this complication really necessary? If the menus are organised into a nice logical hierarchy (as they should be), shouldn't it be easy for people to find the features they need, and shouldn't there be no need to hide features to protect people from them, because people naturally won't go into the parts of the menu that contain the features they don't need? Does QGIS really need a system of standard profiles? Will that actually address the things that are bothering people? Or are other fixes or improvements required to address these? e.g.: - make the "customisation" feature actually capable of hiding buttons in the plugin toolbar. - make "customisations" apply without a restart (I presume this already works on systems, otherwise I don't know what the "apply" button would be for). - make it possible for users to create extra toolbars, and even drag-and-drop buttons between different toolbars. - gui cleanups like the famous unified add layer dialog. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Merging of incompatible changes
> Date: Thu, 25 Oct 2012 07:48:30 +0900 > From: Paolo Cavallini > To: qgis-developer@lists.osgeo.org > Subject: Re: [Qgis-developer] Merging of incompatible changes > Message-ID: <5088703e.3070...@faunalia.it> > Content-Type: text/plain; charset=ISO-8859-1 > > Il 25/10/2012 05:39, Pirmin Kalberer ha scritto: > > We did decide filling the missing gaps to fully replace old > > symbology and old labelling (Paolo: Kickstarter pledge on the way?) and > > polishing the many new features already integrated. > Sorry, no progress on this. I've asked for some feedback and help, got > none. Very little time now, planning to do it ASAP. Any help welcome. > > plugins. It will take years to bring them all in sync with QGIS again. > I understand both Pirmin and Martin concerns. I think seriously breaking > the API and all the plugins will be good *if* we have a serious plan on > how to migrate the plugins. At this stage, we cannot afford releasing a > 2.0 without plugins, as nobody will use it, and we'll get stuck in the > middle of the transition. This had proved to be a major problem for many > software, sometimes effectively killing it, and we should really > seriously avoid them. > I think it is realistic, on the basis of the response to the request to > move plugins to the new infrastructure, to assume that many developers > will not do the migration in time: are we willing and capable of > upgrading them ourselves, or do we plan to leave them as such? When is "on time"? Is it "before 2.0 is released"? When people use software like Firefox they are accustomed to a lot of extensions becoming "incompatible" if they upgrade to a new version when it is released. In that case there is seldom any real benefit associated with the upgrade. But the threading is a major performance improvement, which is worth breaking compatibility isn't it? And people have been eagerly anticipating it for years already... Would you assume that most of those developers who have migrated their plugins to the new infrastructure will also update them for API changes? Wouldn't that mean there isn't much of a problem, because whichever plugins won't be updated aren't available to users in the repository, anyway? ;) Or has someone now migrated a significant number of unmaintained plugins to the new infrastructure? If so, how many? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] User profiles
Hi Alistair, My QGIS setup has 4 toobars across the top of the screen. If I introduce someone to that, who is not familiar with GIS, their eyes glaze over... one lost potential user. Multiplied several times. Is QGIS intended to be used by everyone, from novices to GIS experts? It does not do that well at present (IMHO) hence our significant investment in the simpler Quantum Map application. The current toolbars/menus are confusing. Related tasks are not obviously grouped together - the feature select tool is a critical part of digitising, but the icon is in a different menu... which is confusing and not that logical. QGIS became popular because it could be downloaded & used by almost anyone. The enhancements from v1.0 to now are a fantastic step forward, and bring QGIS to a huge range of more expert users, but at the expense of the traditional ones. I'm sure the current flexible toolbar options can be enhanced to provide a QGIS which can be set up a a simple to learn & use mapping tool, to a bioinformatics or hydrological, etc, GIS workstation. Having dockable toolbars, which users can add & remove icons to/from, & with icons able to be added to multiple toolbars would allow a range of "interface settings", simple, mapping, vector editing (digitising), etc, but also a hydrological, etc toolbar. Plugins could be added to whatever toolbar the user required, to meet their needs. I don't see how adding this capability makes using QGIS harder for anyone, especially if it can be installed with several initial example configurations to choose from. Perhaps the user could manage a set of toolbars (create/delete/edit) and can add whatever icons (tools) they want to any toolbar. Plugins are added as types of tools, & can be added to toolbars. Having an interface to manage tools & toolbars creates a facility which it is very hard to hide tools or functionality, if well implemented. Tool metadata cold be supported, so users could search for "hydrological:, or "digitising" to find a list of those available. Any configuration could be saved & reloaded (even uploaded to an online repository of QGIS GUI congigurations, much like plugins...) Or does something along these lines not have wide appeal? Cheers, Brent Wood --- On Thu, 10/25/12, Alister Hood wrote: From: Alister Hood Subject: Re: [Qgis-developer] User profiles To: "qgis-developer@lists.osgeo.org" Date: Thursday, October 25, 2012, 3:28 PM > Date: Wed, 24 Oct 2012 09:56:47 +0700 > From: Marco Bernasocchi > To: qgis-developer@lists.osgeo.org > Subject: Re: [Qgis-developer] User profiles > Message-ID: <508758ef.4030...@bernawebdesign.ch> > Content-Type: text/plain; charset=ISO-8859-1 > > On 10/24/2012 09:53 AM, Alister Hood wrote: > > Hi guys, > > > >> Date: Tue, 23 Oct 2012 18:43:50 +0200 > >> From: Martin Dobias > >> To: Paolo Cavallini > >> Cc: qgis-developer > >> Subject: Re: [Qgis-developer] User profiles > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=ISO-8859-1 > >> > >> Hi Paolo > >> > >> On Tue, Oct 23, 2012 at 2:56 PM, Paolo Cavallini > >> wrote: > >>> Hi all. > >>> The discussion of this evening brought a nice idea: since we have many > >>> different types of users, whi not having a "first usage wizard" that > >>> simply asks the user which profile (s)he prefers, and then starts QGIS > >>> with only the needed menus and buttons activated? The profiles can be > >>> easily produced via the customization menu, so this seems trivial to > >>> implement, and can greatly help first-time users and special interest > >>> groups. > >>> Of course we have to have a prominent menu to re-run the wizard, and > >>> change the choice. > >>> Opinions? > >> > >> I am just afraid that with such profiles the users may forget after a > >> while they have chosen a "first-time user" profile that disables a lot > >> of functionality and then users will ask/complain about missing > >> features...? > > > > Yes, I can see why you might want to offer some default "profiles" to > > control which toolbars and panels are visible, but I don't think it is a > > good idea to use the customisation feature to hide any functionality. > > > can you elaborate on why? Here is my train of thought: If there was a system of different profiles, I imagine they should be task oriented, e.g. "raster analysis" or "hydrological modelling" (rather than "view", "edit" and "analyse" or "beginner", "expert" and "master of the known universe"). If the profiles used the "customisation" mechanism, they would not just control which toolbars and panels are on or off by default, they would control which toolbars are actually visible in the right-click menu and able to be turned on or off there. As well as hiding toolbars and panels, it is natural that specific menu entries and toolbar buttons would be hidden in each profile, and when a user needed a specific feature they would need to switch through several profiles lookin
Re: [Qgis-developer] Merging of incompatible changes
Hi I understand Paolos and Pirmins concerns. Software like kde4 or gvsig had or still have a long time of problems with major new versions. On the other hand, I don't want to postpone the threading changes again and again. Would it be an option to branch a 1.9 from current master just before Martin merges the first breaking changes? That way, there would be a version with all the nice 1.9 features and very little API breaks (and 99% of the plugins working). Plus the shapefile encoding fix. I remember though that the 1.9 option was shortly discussed in Essen and the release team was not very pleased about it. I can't remember the exact reasons, maybe it is worth to reconsider? Regards, Marco On 25.10.2012 00:48, Paolo Cavallini wrote: Il 25/10/2012 05:39, Pirmin Kalberer ha scritto: We did decide filling the missing gaps to fully replace old symbology and old labelling (Paolo: Kickstarter pledge on the way?) and polishing the many new features already integrated. Sorry, no progress on this. I've asked for some feedback and help, got none. Very little time now, planning to do it ASAP. Any help welcome. plugins. It will take years to bring them all in sync with QGIS again. I understand both Pirmin and Martin concerns. I think seriously breaking the API and all the plugins will be good *if* we have a serious plan on how to migrate the plugins. At this stage, we cannot afford releasing a 2.0 without plugins, as nobody will use it, and we'll get stuck in the middle of the transition. This had proved to be a major problem for many software, sometimes effectively killing it, and we should really seriously avoid them. I think it is realistic, on the basis of the response to the request to move plugins to the new infrastructure, to assume that many developers will not do the migration in time: are we willing and capable of upgrading them ourselves, or do we plan to leave them as such? We are on a developer list here. As a developer I like the proposed changes very much. QGIS is made by developers, but is also made for users. And sometimes we should care about users - even the 99% Windows users. That's why I'm voting for a polished 2.0 release in a few month with the great feature set we already have. +1: let's release ASAP. Please note that, as said in Essen, we can start preparing for a 3.0 release as soon as 2.0 is out, no need to wait years for that. One side note: current stable version is basically unusable as a default for all double-byte-characters people (> half of the world population). The needed change is trivial, a new release could fix this easily. All the best. -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Weberstrasse 5, CH-8004 Zürich, 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] again on encoding problems
Thanks maris. Are grass dev aware of the problem? Could we then display grass in English when on windows, for these languages? It seems important. All the best. Maris Nartiss ha scritto: >Hello Paolo, >I haven't seen how QGIS GRASS plug in is built, still my 0.02 from >GRASS side. Some time a go I investigated encoding problems in native >GRASS on Windows (WinGRASS) and my conclusion was - it is not possible >to fix it for GRASS 6 due to character encoding handling in Windows. >Reason was simple - there's no single coding to cover all use cases in >Windows (CLI has one system (OEM), GUI has it's legacy system (ANSI) >and add to all also Unicode in more recent code). As GRASS strings >might come in all three encodings, unless the source of string is >known, it's impossible to convert/display string correctly. > >Somebody with greater QGIS part can correct me, if I'm wrong (as I >would like to be :) ). > >Maris. > >PS. http://lists.osgeo.org/pipermail/grass-dev/2011-March/053874.html > >2012/10/24 Paolo Cavallini : >> Hi all. >> Here in the Far East the encoding is a serious problem hampering the >use >> of QGIS. >> I was just pointed out a problem with the GRASS plugin on Win: >> http://hub.qgis.org/issues/4547 >> and the solution the use: >> >http://osgeo-org.1560.n6.nabble.com/Qgis1-5-Grass-tt3730164.html#a3730165 >> basically they set up the entire environment in EN, but this is not >> optimal, as the translation is actually there, as we can see e.g. on >osx >> and of course on Linux. >> It looks a very simple problem, anybody has an idea on how to solve >it >> more elegantly? >> All the best, and thanks. >> >> -- >> Paolo Cavallini - Faunalia >> www.faunalia.eu >> Full contact details at www.faunalia.eu/pc >> Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario >> >> ___ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://faunalia.it/pc___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
