Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
On 03/26/2014 05:21 PM, kimaidou wrote: * display the legend as an interactive tree to let the user deactivate one or several rules or classes. Toggling one of the classes will just hide the corresponding features in the map. I think the feature would be a great addition, but it is a different approach that just diplsaying an image. What about having both options if possible : the user could decide layer per layer if the legend must be interactive (with checkboxes) or if he just want a static image to be generated and displayed. I would love to have this feature when exploring new datasets. In addition to the checkbox for each layer, another (smaller?) checkbox could be added near each class, allowing to easily toggle visibility of each class. It would also need a way to toggle all classes visibility at once. This is actually trivial on the UI side, but I don't know how easy it is to control the rendering of a single class ? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Hi, after checking with other colleagues, waiting that your refactoring is finished is ok for us. We will focuse on user specifications during your refactoring so that we can launch a contract soon after. Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Vienna-hackfest-QGIS-Legend-discussion-tp5131063p5133062.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] Vienna hackfest: QGIS Legend discussion
Hi Martin, thanks a lot for your feedback. I have some questions: Martin Dobias wrote Hi First of all thanks everyone who contributed to this thread - there were many interesting ideas that we can discuss further. On Mon, Mar 31, 2014 at 10:32 AM, Régis Haubourg lt; regis.haubourg@ gt; wrote: Some questions here since French users are really interested in that work, and need some info before being able to fund some work : - I saw Lutra Consulting calls for fundings on that item. Is the budget fullfilled or are you still looking for funds? [ We are still looking for funds for the project (so far we have reached ~70% of the goal) - and therefore contributions are welcome! - We previously discussed of legend for size varying symbols and diagrams [0]. Is that also included in that work? This is not part of the refactoring work, but it is very interesting use case and therefore I will keep it in mind and do the design in a manner that adding such functionality should be possible. Advanced legend manipulation could be another followup project. Hi Martin, does that mean that we need to wait that your refactoring is finished before starting a work on proportionnal legends? What is the target version for that? This is a high priority use case here, should we fund a temporary plugin for current versions ? This is sub-optimal too me, and that requires also we fund first a plugin, and secondly a core feature. Martin Dobias wrote - Can some give us some conclusions of what what said in codesprint legend workgroup on this? (sorry for not being able to come and contribute there) While we have discussed various aspects, we have not reached too many conclusions :-) - legend vs layer manager - there was a good point that we are mixing the concept of map legend and layer manager into one tree. While these are related, they get into conflicts... while layer manager should be a tool for management of the map (and be as powerful as possible), map legend should provide mainly the help for the user to identify the map elements (and be as simple as possible). Are you heading to an arcmap like solution with different tabs in layer registry? Martin Dobias wrote - support for multiple canvases - while it is not the intent to have this functionality when the refactoring is complete, the work should bring us a bit closer to that. It is still unclear how multiple canvases should behave as there are lots of use cases with different needs, e.g.: - tabbed vs split screen canvases - same or different map extent - same or different layer styles - same or different set of layers / visibility after having experienced Mapinfo, Arcmap, and QGIS dockable Mirror map, I think Multi Canvas is really required for multi map composers, and current arcmap design is rather good. We still need Dockable mirror map for on screen visulisation purposes. Martin Dobias wrote - new functionality suggested - we discussed some of the ideas from the thread, especially the ones from Olivier. No conclusion was reached whether to adopt all of them in the future, but the icons as indicators for labeling, diagrams, snapping, actions, editing(?) etc were seen as potentially very useful. They could be even used for reporting map canvas refresh progress (animated wait icon) or errors/warnings (e.g. reprojection failed). I am sure there were more things discussed which I have forgotten already, other participants please feel free to add your impressions. Regards Martin ___ Qgis-developer mailing list Qgis-developer@.osgeo http://lists.osgeo.org/mailman/listinfo/qgis-developer Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Vienna-hackfest-QGIS-Legend-discussion-tp5131063p5132638.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] Vienna hackfest: QGIS Legend discussion
On 2 April 2014 11:55, Régis Haubourg regis.haubo...@eau-adour-garonne.frwrote: Hi Martin, does that mean that we need to wait that your refactoring is finished before starting a work on proportionnal legends? What is the target version for that? This is a high priority use case here, should we fund a temporary plugin for current versions ? This is sub-optimal too me, and that requires also we fund first a plugin, and secondly a core feature. I suggest you to wait... every ad-hoc solution would be refactored again after release of the new Legend architecture. Actual design is really limited... the new one will use all the potential of Qt legend items customization. One of the Martin's work will be moving legend to gui library allowing programmatically (e.g using plugins) add new item visualization modes In this moment of the process, as stated by Martin, we're collecting all the default visualization features that legend should have. after having experienced Mapinfo, Arcmap, and QGIS dockable Mirror map, I think Multi Canvas is really required for multi map composers, and current arcmap design is rather good. We still need Dockable mirror map for on screen visulisation purposes. I don't know if you know that exist Dockable Mirror Map plugin that add this functionality to Qgis... new legend interface will be designed to allow different rendering/styling for each available canvas. se you, Luigi Pirelli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Hi Régis On Wed, Apr 2, 2014 at 11:55 AM, Régis Haubourg regis.haubo...@eau-adour-garonne.fr wrote: This is not part of the refactoring work, but it is very interesting use case and therefore I will keep it in mind and do the design in a manner that adding such functionality should be possible. Advanced legend manipulation could be another followup project. Hi Martin, does that mean that we need to wait that your refactoring is finished before starting a work on proportionnal legends? What is the target version for that? The refactoring is a requirement for such thing - the goal of that work is really to allow greater flexibility of legend widget. The plan is to get it into 2.4 release. This is a high priority use case here, should we fund a temporary plugin for current versions ? This is sub-optimal too me, and that requires also we fund first a plugin, and secondly a core feature. Unfortunately I do not think it would be possible to have a plugin that would show the proportional legend directly in legend widget or composer legend. Maybe a plugin that would just generate an image with proportional legend so it could be included in composition - not a great solution. I can imagine a python plugin for QGIS =2.4 that would add this functionality. - legend vs layer manager - there was a good point that we are mixing the concept of map legend and layer manager into one tree. While these are related, they get into conflicts... while layer manager should be a tool for management of the map (and be as powerful as possible), map legend should provide mainly the help for the user to identify the map elements (and be as simple as possible). Are you heading to an arcmap like solution with different tabs in layer registry? I'm not really sure what you mean... maybe a screenshot would help. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Hi again, -Message d'origine- De : Martin Dobias [mailto:wonder...@gmail.com] Envoyé : mercredi 2 avril 2014 13:15 À : HAUBOURG Cc : qgis-dev Objet : Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion Hi Régis On Wed, Apr 2, 2014 at 11:55 AM, Régis Haubourg regis.haubourg@eau- adour-garonne.fr wrote: This is not part of the refactoring work, but it is very interesting use case and therefore I will keep it in mind and do the design in a manner that adding such functionality should be possible. Advanced legend manipulation could be another followup project. Hi Martin, does that mean that we need to wait that your refactoring is finished before starting a work on proportionnal legends? What is the target version for that? The refactoring is a requirement for such thing - the goal of that work is really to allow greater flexibility of legend widget. The plan is to get it into 2.4 release. [RH] OK, that is sufficient for me, but I will ask other state services we are trying to coordinate if an higher urgency is there. This is a high priority use case here, should we fund a temporary plugin for current versions ? This is sub-optimal too me, and that requires also we fund first a plugin, and secondly a core feature. Unfortunately I do not think it would be possible to have a plugin that would show the proportional legend directly in legend widget or composer legend. Maybe a plugin that would just generate an image with proportional legend so it could be included in composition - not a great solution. I can imagine a python plugin for QGIS =2.4 that would add this functionality. [RH] Yes, as Gino says, generating an image is a bad solution. We might be just consolidating LegendSVG plugin if urgency is there. - legend vs layer manager - there was a good point that we are mixing the concept of map legend and layer manager into one tree. While these are related, they get into conflicts... while layer manager should be a tool for management of the map (and be as powerful as possible), map legend should provide mainly the help for the user to identify the map elements (and be as simple as possible). Are you heading to an arcmap like solution with different tabs in layer registry? [RH] Don't you have a licence ;-) ? See here [0] what esri calls as dataframe. This is a meta layer group. Only one is activated in mapcanvas. But when user switch to composer view (in the same window, just a small button in status toolbar), then each map object of the composer is a different dataframe. This is much nicer than having to play with lock layers checkbox and mapcanvas status. I see users here tends to have one layer group for each map object in multimap composers.. so we're not so far from a user point of view. We just need that new meta layer group.. Of course, that's much more complicated in API. I'm not really sure what you mean... maybe a screenshot would help. Regards Martin [RH] Concerning the basic requirements for proportional legends, that's what we have in mind: - minimal support of proportional symbol sizes in layer registry for point symbols and lines, we just need here 3 symbols with a size + values of these symbols . see [2] - functional size symbol only for simple symbols composed of 1 marker: - graduated , categorized and ruled base renderer using no data defined setting. - data defined point size or line width and current advanced proportion field (to be merged with data defined settings see [1]). This use case is more tricky, since we have to read actual data to generate some legend, and we need some user input to choose min and max size and values for legend symbols. See Mapinfo gui [3]. Middle symbol can be generated using active expression, user shouldn't have to take care of this. - support for cleaner legends in composer. We can imagine different layouts and have more classes in legend. See [4] [0] http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//0066000400 [1] http://osgeo-org.1560.x6.nabble.com/Duplication-of-functionality-Data-defined-size-and-Size-scale-field-td5131007.html#a5131122 [2] https://dl.dropboxusercontent.com/u/72368800/arcmap_prop_symbol3.png [3] https://dl.dropboxusercontent.com/u/72368800/mapinfo_proportionnal_symbols.png [4] https://dl.dropboxusercontent.com/u/72368800/possible_proportionnal_symbols_legends.png ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Hi First of all thanks everyone who contributed to this thread - there were many interesting ideas that we can discuss further. On Mon, Mar 31, 2014 at 10:32 AM, Régis Haubourg regis.haubo...@eau-adour-garonne.fr wrote: Some questions here since French users are really interested in that work, and need some info before being able to fund some work : - I saw Lutra Consulting calls for fundings on that item. Is the budget fullfilled or are you still looking for funds? [ We are still looking for funds for the project (so far we have reached ~70% of the goal) - and therefore contributions are welcome! - We previously discussed of legend for size varying symbols and diagrams [0]. Is that also included in that work? This is not part of the refactoring work, but it is very interesting use case and therefore I will keep it in mind and do the design in a manner that adding such functionality should be possible. Advanced legend manipulation could be another followup project. - Can some give us some conclusions of what what said in codesprint legend workgroup on this? (sorry for not being able to come and contribute there) While we have discussed various aspects, we have not reached too many conclusions :-) - legend vs layer manager - there was a good point that we are mixing the concept of map legend and layer manager into one tree. While these are related, they get into conflicts... while layer manager should be a tool for management of the map (and be as powerful as possible), map legend should provide mainly the help for the user to identify the map elements (and be as simple as possible). - support for multiple canvases - while it is not the intent to have this functionality when the refactoring is complete, the work should bring us a bit closer to that. It is still unclear how multiple canvases should behave as there are lots of use cases with different needs, e.g.: - tabbed vs split screen canvases - same or different map extent - same or different layer styles - same or different set of layers / visibility - new functionality suggested - we discussed some of the ideas from the thread, especially the ones from Olivier. No conclusion was reached whether to adopt all of them in the future, but the icons as indicators for labeling, diagrams, snapping, actions, editing(?) etc were seen as potentially very useful. They could be even used for reporting map canvas refresh progress (animated wait icon) or errors/warnings (e.g. reprojection failed). I am sure there were more things discussed which I have forgotten already, other participants please feel free to add your impressions. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Martin Dobias wrote Some items from my wishlist: - make legend available in GUI library - split legend into model/view architecture - allow more flexible display of symbology in legend - make legend easily customizable - inline editing of symbols Hi , Some questions here since French users are really interested in that work, and need some info before being able to fund some work : - I saw Lutra Consulting calls for fundings on that item. Is the budget fullfilled or are you still looking for funds? [ - We previously discussed of legend for size varying symbols and diagrams [0]. Is that also included in that work? - Can some give us some conclusions of what what said in codesprint legend workgroup on this? (sorry for not being able to come and contribute there) [0] http://osgeo-org.1560.x6.nabble.com/Legend-for-proportionnal-symbols-and-expression-based-symbols-td5092635.html -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Vienna-hackfest-QGIS-Legend-discussion-tp5131063p5132189.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] Vienna hackfest: QGIS Legend discussion
Hi ! *Bernhard Ströbl :* but if different symbologies why not having different labels or different diagrams. This would become too complicated, I am afraid. Good point... I'm not sure if would be a good idea to have the symbology as a tag anyways, since every layer will necessarily have one, and it's a bit more than just an optional addition to a layer, like the other tags are. The only thing I'd like about having the symbology as a tag, is that it would be easy to copy styles from one layer to another. But maybe, the current copy/paste style is enough, especially since it's not that frequent to copy symbologies from one layer to another. Bernhard Ströbl : Or better gray them out to be consistent with the rest (grayed out = not visible) but keep their check state. Layers could even be grayed out because they have no feature in the current map extent. So a grey layer name would indicate that you cannot see this layer in the current map. Possible reasons are: 1) layer is not set visible 2) scale thresholds are not matching current map scale 3) no features in current map extent Ok for 12, but I find 3 is an overkill. Not seeing the content because of looking somewhere else doesn't mean the data is hidden. It may make the whole graying out of invisible layers thing less readable. But another reason to gray out would be the data source is unavailable. I updated the mockup, with the aligned tags. I find it more clear and it may solve the concern of the width for small screens : it would be possible to completely fold the tags part (and maybe even the sources part), so to display the legend as it is now. About the opacity/blending mode, I think the most consistent UI implementation would be to use tags as well : any layer with no (or disabled) blending tag has 100% + normal (or transfer for groups). Changing those would require a blending tag. I'll see if I manage to open a wiki page so once we've got an agreement on the mockup we can keep reference to it. Best, Olivier [image: Images intégrées 1] ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Hi Olivier, first: I like the new mockup, more comments below Am 27.03.2014 12:41, schrieb Olivier Dalang: Hi ! *Bernhard Ströbl :* but if different symbologies why not having different labels or different diagrams. This would become too complicated, I am afraid. Good point... I'm not sure if would be a good idea to have the symbology as a tag anyways, since every layer will necessarily have one, and it's a bit more than just an optional addition to a layer, like the other tags are. The only thing I'd like about having the symbology as a tag, is that it would be easy to copy styles from one layer to another. But maybe, the current copy/paste style is enough, especially since it's not that frequent to copy symbologies from one layer to another. I would not say that ... besides copying labels or diagrams might be even more seldom. In order to be consistent I would favour symbology as a tag, too. Why do I have to use a context menu to copy the style while I can make a simple drag and drop for the diagram? Bernhard Ströbl : Or better gray them out to be consistent with the rest (grayed out = not visible) but keep their check state. Layers could even be grayed out because they have no feature in the current map extent. So a grey layer name would indicate that you cannot see this layer in the current map. Possible reasons are: 1) layer is not set visible 2) scale thresholds are not matching current map scale 3) no features in current map extent Ok for 12, but I find 3 is an overkill. Not seeing the content because of looking somewhere else doesn't mean the data is hidden. It may make the whole graying out of invisible layers thing less readable. Hm, difficult, I could argue looking with a different scale does not mean the data is hidden. The map canvas has a current scale and a current view port. Why should only the scale qualify for graying out and not the viewport? But another reason to gray out would be the data source is unavailable. good addition Bernhard I updated the mockup, with the aligned tags. I find it more clear and it may solve the concern of the width for small screens : it would be possible to completely fold the tags part (and maybe even the sources part), so to display the legend as it is now. About the opacity/blending mode, I think the most consistent UI implementation would be to use tags as well : any layer with no (or disabled) blending tag has 100% + normal (or transfer for groups). Changing those would require a blending tag. I'll see if I manage to open a wiki page so once we've got an agreement on the mockup we can keep reference to it. Best, Olivier Images intégrées 1 __ Information from ESET Security, version of virus signature database 9601 (20140327) __ The message was checked by ESET Security. part000.txt - is OK http://www.eset.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Hi Olivier, I like your ideas, currently the layer settings dialog is a bit crowded and easy access is certainly a plus. More comments below. Am 26.03.2014 01:07, schrieb Olivier Dalang: Hi ! Great news ! (by the way, I'm crossposting to qgis-ux as well) I've been thinking about this a little and have some more long term ideas I want to share (see the mockup below, it may be more clear): 1. Trivalent checkboxes (neutral, visible, hidden) (#5787) When neutral, a layer/group is shown if it's parent is shown (top level neutral elements are shown). When hidden, a layer/group is hidden regardless of its parents. When visible, a layer/group is shown regardless of its parents. This would make big groups much more usable. Cinema4D's object manager features this, and its very efficient. Also Qt's checkboxes can be tristate out of the box, so it may not be that hard to implement. 2. Display the data source as an icon in a column on the left (not indented, separated by a thin vertical line) The icon would help to know whether it's a WMS, Shapefile, postgis, etc. layer. The icon would be grayed out when the source is unavailable. Right clicking on the source would only source related actions (subset, relink source, save data as, open in db manager, ...). It would make the distinction between layer and source much clearer. This distinction is obvious for experienced GIS users, but I've seen a lot of beginners being very confused because of that (software working with external links/files are quite rare for common usage). We could also display the edit pencil on the source, giving one more hint to the user that he's not modifying the QGIS file, but the datasource behind. What you write about beginners is also my experience in several courses. So a big +1! I would like the distinction between layer and source related settings. 3. Display labels/diagrams/actions/etc. as icons just after the layer's name Allow for quick toggling of those frequently useful features. Right clicking allow for related actions (edit, set label expression, etc.) Imagine what plugins could add there !! Any per-layer setting could be shown as a tag. Think of Anita's TimeManager or Minoru's qgis2ThreeJs... We could put the snap settings there too, or new features like alternative styles, saved feature selections, snap settings, !!! Hm, some thoughts (all IMHO): - wouldn't it be more intuitive to left click on an icon (which would then open the layer settings with the appropriate section). Right clicking in the way you describe could be implemented additionally. - Although this would be nice to have it makes the legend a lot broader which might be a problem on smaller screens. - I would not put diagrams there as they are much more seldomly used than labels. I think most common usage is the style but I cannot see an icon for this in your mockup. - +1 for having the snap options there (in addition to the dialog we have now). - The current behavior (opening settings by double clicking/context menu on the layer name) should stay. I understand your proposal as an additional way to get there. Bernhard Again, this is how Cinema4D's manager works (they call those icons tags, and C4D makes extensive use of them). In their version, they align all the tags after another vertical bar, which may be the most elegant way to solve the layout with long layer's names. Conclusion. I think it's worth making the Legend GUI a bit more rich than it is now. This is the part of the GUI where the users spend most of their clicks, and IMO the potential efficiency bonus is by far worth the small complexification. And it's not only complexification, it's also clarification. The segregation of source/layer/addendi in the legend GUI will be very powerful in combination with contextual menus. By having three different contextual menus, we'll be able to have much more actions at finger tips, without over-crowding the menus. About Nyall's idea : +1 ! It could be implemented as it is in Photoshop, i.e. group's blending mode is transfer by default, which simply draws the children as if there was no group. But setting the group's blending mode to anything else (normal,multiply,...) composites the group as one layer, and blends that composition. Having this in the legend UI rather than in the layer style would also make the UI much clearer. Right now, the UI is a bit confusing because the transparency at layer level, feature level, and at color alpha level are almost at the same place. In general, using Photoshop as a reference for the UI in regard of layers/blending modes makes much sense since PS is the leader in that matter (as a remainder, they just have a drop-down menu at the top of the layer panel which applies to the selected layer). What do you think ? If the community likes the principles, I'd be happy to work on the mockup a bit more (by integrating Nydall's suggestion), so we can have a common reference for further
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
+1 ! really nice mockup. I would add another visibility state for layers that are checked, but are not visible due to scale visualisation threshold. A word about tooltips over those elements. We could then have the current datasource tooltip on the datasource icon, and a tooltip showing metadata title and details of the layer, when the mouse goes over the layer's title. Finally, I we manage to have working legend for varying size , we should take attention that some symbols could be larger than today. Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Vienna-hackfest-QGIS-Legend-discussion-tp5131063p5131124.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] Vienna hackfest: QGIS Legend discussion
Hi again ! *Bernhard Ströbl* : - wouldn't it be more intuitive to left click on an icon (which would then open the layer settings with the appropriate section). Right clicking in the way you describe could be implemented additionally. I think the left click on an icon could simply toggle the setting on/off. Opening the layer settings could be the first item in the context-menu + middle click + shift or control click, so it's easily accessible. But I agree the central place to define the settings should remain in the layer properties dialog (even if I find we should emphasize the distinction between data/layer a bit more in this dialog too). - I would not put diagrams there as they are much more seldomly used than labels. I think most common usage is the style but I cannot see an icon for this in your mockup. I thought the icons would be shown only if relevant. Of course it makes no sense to display a diagram label for every layer, but it makes a lot of sense to display it for the one or two layers that do display diagrams. The user could delete those icons, which would simply disable them, and to display them again, one would have to reenable the corresponding feature from within the main layer properties dialog. And it's true that symbology the could be displayed as an icon too. Maybe one could have several symbologies on one layer, and clicking them would simply activate one (and deactivate the others), since toggling off a symbology doesn't make sense. One very powerful and intuitive feature would then be to be able to move/copy those icons from one layer to another. A very convenient an easy way to copy symbology/labelling style/snap settings etc. (I think I read some discussions about implementing the ability to copy/paste/import/export only parts of the layer's properties). Again, that's exactly how C4D works, and it's very pleasant to use. I'd be happy to make some screencasts if you think it may make it more clear how this works. - The current behavior (opening settings by double clicking/context menu on the layer name) should stay. I understand your proposal as an additional way to get there. Yes definitely. Régis Haubourg : I would add another visibility state for layers that are checked, but are not visible due to scale visualisation threshold. True, that should be displayed in the legend too. It could be an icon too (again, this would allow for easy and consistent copy/move/enable). If the icons support different visual states. Best, Olivier ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Am 26.03.2014, 01:07 Uhr, schrieb Olivier Dalang olivier.dal...@gmail.com: Nice mockup Oliver! I like the idea of putting the tag icons after another vertical bar since I hope that it would look cleaner if the icons are aligned. Looking forward to the discussion. Best wishes, Anita -- anitagraser.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Hi all This discussion is very interesting indeed. I am thinking about some features we already talked about in the past and which could be great to have (but which can be antinomic...) * let the user choose an image for the legend instead of the QGIS image. SVG would be the best format for this. Imagine complicated expression based rules. I am not sure we can have an robust programmatic way to build an automatic legend image taking all QGIS style capabilities into account (expressions, rules, blending mode, etc.). Sometimes, an SVG image made in Inkscape would be the way to go * display the legend as an interactive tree to let the user deactivate one or several rules or classes. Toggling one of the classes will just hide the corresponding features in the map. I think the feature would be a great addition, but it is a different approach that just diplsaying an image. What about having both options if possible : the user could decide layer per layer if the legend must be interactive (with checkboxes) or if he just want a static image to be generated and displayed. * As Regis Haubourg often recall, it could be great to have an option to parse the vector layer data and display a legend which takes expressions based style into account, for example for proportionnal circles or coulours depending on an expression. But as I said before, it can be tricky to generate a good looking image for some styles; Michael 2014-03-26 9:59 GMT+01:00 Anita Graser anitagra...@gmx.at: Am 26.03.2014, 01:07 Uhr, schrieb Olivier Dalang olivier.dal...@gmail.com : Nice mockup Oliver! I like the idea of putting the tag icons after another vertical bar since I hope that it would look cleaner if the icons are aligned. Looking forward to the discussion. Best wishes, Anita -- anitagraser.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] Vienna hackfest: QGIS Legend discussion
Hi Olivier, Am 26.03.2014 09:29, schrieb Olivier Dalang: Hi again ! *Bernhard Ströbl* : - wouldn't it be more intuitive to left click on an icon (which would then open the layer settings with the appropriate section). Right clicking in the way you describe could be implemented additionally. I think the left click on an icon could simply toggle the setting on/off. Opening the layer settings could be the first item in the context-menu + middle click + shift or control click, so it's easily accessible. But I agree the central place to define the settings should remain in the layer properties dialog (even if I find we should emphasize the distinction between data/layer a bit more in this dialog too). - I would not put diagrams there as they are much more seldomly used than labels. I think most common usage is the style but I cannot see an icon for this in your mockup. I thought the icons would be shown only if relevant. Of course it makes no sense to display a diagram label for every layer, but it makes a lot of sense to display it for the one or two layers that do display diagrams. The user could delete those icons, which would simply disable them, and to display them again, one would have to reenable the corresponding feature from within the main layer properties dialog. And it's true that symbology the could be displayed as an icon too. Maybe one could have several symbologies on one layer, and clicking them would simply activate one (and deactivate the others), since toggling off a symbology doesn't make sense. ok, makes sense to me but if different symbologies why not having different labels or different diagrams. This would become too complicated, I am afraid. One anything per layer is ok IMHO. If you need several symbologies use several layers or rules. One very powerful and intuitive feature would then be to be able to move/copy those icons from one layer to another. A very convenient an easy way to copy symbology/labelling style/snap settings etc. (I think I read some discussions about implementing the ability to copy/paste/import/export only parts of the layer's properties). I like this idea! Again, that's exactly how C4D works, and it's very pleasant to use. I'd be happy to make some screencasts if you think it may make it more clear how this works. - The current behavior (opening settings by double clicking/context menu on the layer name) should stay. I understand your proposal as an additional way to get there. Yes definitely. Régis Haubourg : I would add another visibility state for layers that are checked, but are not visible due to scale visualisation threshold. True, that should be displayed in the legend too. It could be an icon too (again, this would allow for easy and consistent copy/move/enable). If the icons support different visual states. Or better grey them out to be consistent with the rest (greyed out = not visible) but keep their check state. Layers could even be greyed out because they have no feature in the current map extent. So a grey layer name would indicate that you cannot see this layer in the current map. Possible reasons are: 1) layer is not set visible 2) scale thresholds are not matching current map scale 3) no features in current map extent best regards Bernhard __ Information from ESET Security, version of virus signature database 9595 (20140326) __ The message was checked by ESET Security. part000.txt - is OK http://www.eset.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
Hi ! Great news ! (by the way, I'm crossposting to qgis-ux as well) I've been thinking about this a little and have some more long term ideas I want to share (see the mockup below, it may be more clear): 1. Trivalent checkboxes (neutral, visible, hidden) (#5787) When neutral, a layer/group is shown if it's parent is shown (top level neutral elements are shown). When hidden, a layer/group is hidden regardless of its parents. When visible, a layer/group is shown regardless of its parents. This would make big groups much more usable. Cinema4D's object manager features this, and its very efficient. Also Qt's checkboxes can be tristate out of the box, so it may not be that hard to implement. 2. Display the data source as an icon in a column on the left (not indented, separated by a thin vertical line) The icon would help to know whether it's a WMS, Shapefile, postgis, etc. layer. The icon would be grayed out when the source is unavailable. Right clicking on the source would only source related actions (subset, relink source, save data as, open in db manager, ...). It would make the distinction between layer and source much clearer. This distinction is obvious for experienced GIS users, but I've seen a lot of beginners being very confused because of that (software working with external links/files are quite rare for common usage). We could also display the edit pencil on the source, giving one more hint to the user that he's not modifying the QGIS file, but the datasource behind. 3. Display labels/diagrams/actions/etc. as icons just after the layer's name Allow for quick toggling of those frequently useful features. Right clicking allow for related actions (edit, set label expression, etc.) Imagine what plugins could add there !! Any per-layer setting could be shown as a tag. Think of Anita's TimeManager or Minoru's qgis2ThreeJs... We could put the snap settings there too, or new features like alternative styles, saved feature selections, snap settings, !!! Again, this is how Cinema4D's manager works (they call those icons tags, and C4D makes extensive use of them). In their version, they align all the tags after another vertical bar, which may be the most elegant way to solve the layout with long layer's names. Conclusion. I think it's worth making the Legend GUI a bit more rich than it is now. This is the part of the GUI where the users spend most of their clicks, and IMO the potential efficiency bonus is by far worth the small complexification. And it's not only complexification, it's also clarification. The segregation of source/layer/addendi in the legend GUI will be very powerful in combination with contextual menus. By having three different contextual menus, we'll be able to have much more actions at finger tips, without over-crowding the menus. About Nyall's idea : +1 ! It could be implemented as it is in Photoshop, i.e. group's blending mode is transfer by default, which simply draws the children as if there was no group. But setting the group's blending mode to anything else (normal,multiply,...) composites the group as one layer, and blends that composition. Having this in the legend UI rather than in the layer style would also make the UI much clearer. Right now, the UI is a bit confusing because the transparency at layer level, feature level, and at color alpha level are almost at the same place. In general, using Photoshop as a reference for the UI in regard of layers/blending modes makes much sense since PS is the leader in that matter (as a remainder, they just have a drop-down menu at the top of the layer panel which applies to the selected layer). What do you think ? If the community likes the principles, I'd be happy to work on the mockup a bit more (by integrating Nydall's suggestion), so we can have a common reference for further development. Anyways, I'm very happy to know some improvements are in preparation ! Kind regards, Olivier [image: Images intégrées 1] ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vienna hackfest: QGIS Legend discussion
On 26 March 2014 11:07, Olivier Dalang olivier.dal...@gmail.com wrote: 3. Display labels/diagrams/actions/etc. as icons just after the layer's name Allow for quick toggling of those frequently useful features. Right clicking allow for related actions (edit, set label expression, etc.) A big +1 to this from me. Having an immediately accessible label toggle checkbox in the layer control is one of the few things MapInfo does right... Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
