Vienna hackfest: QGIS Legend discussion

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Vienna hackfest: QGIS Legend discussion

Martin Dobias
Hi Vienna hackfest participants

tomorrow (Wednesday) I would like to have a session on QGIS Legend
(the thing on the left side of map canvas) and its future - starting
from 10:00. I am planning some refactoring of the legend widget and it
would be great to discuss various possible future use cases - the
refactoring may help to make our dreams come true :-)

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

Cheers
Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Marco Lechner - FOSSGIS e.V.
hi,

just a little input from my last QGIS beginners course. Many (!)
participants did not understand that toggling a layer group swutches ALL
layers on/off instead of the visible layers. Infact if some layers of a
group are visible toggling the group activates ALL layers (and may
result in QGIS trying to render a big bunch of layers).

May be there are alternative (or customizable) ideas.

Marco

Am 25.03.2014 21:16, schrieb Martin Dobias:

> Hi Vienna hackfest participants
>
> tomorrow (Wednesday) I would like to have a session on QGIS Legend
> (the thing on the left side of map canvas) and its future - starting
> from 10:00. I am planning some refactoring of the legend widget and it
> would be great to discuss various possible future use cases - the
> refactoring may help to make our dreams come true :-)
>
> 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
>
> Cheers
> Martin
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Nyall Dawson
In reply to this post by Martin Dobias
On 26 March 2014 07:16, Martin Dobias <[hidden email]> wrote:
> Hi Vienna hackfest participants
>
> tomorrow (Wednesday) I would like to have a session on QGIS Legend
> (the thing on the left side of map canvas) and its future - starting
> from 10:00. I am planning some refactoring of the legend widget and it
> would be great to discuss various possible future use cases - the
> refactoring may help to make our dreams come true :-)
>

Martin - I'm not sure if it falls outside of the scope of this but an
idea which has been bouncing around my head is the ability to set
transparency and blending options for a layer group. Here's how I
think it should work:

- Have a setting for layer groups for something like "render child
layers together"
- If this is set, then all child layers from that group are first
composited together onto a blank image using their individual layer
blending/transparency settings
- This entire group image is then composited onto the map using the
group's transparency/blending setting

There's two main use cases I can see which would benefit from this:
1. I've played with exposing the various QPainter masking blend modes
to QGIS (see DestinationOver, SourceIn/DestinationIn and
SourceOut/DestinationOut at
http://doc.qt.digia.com/qq/qq17-compositionmodes.html ). However,
since these modes currently apply to all underlying layers in the
stack (including the canvas background color) the end result is
confusing and not very useful. If the scope of the masking operation
was restricted by the process outlined above then it would be possible
for these masking modes to only apply to underlying child layers from
the same layer group.

2. Sometimes it's cartographically desirable to have several layers
completely obscure each other (100% opacity), but be rendered as a
group with some level of transparency.

I'm happy to code this up myself sometime, but if changes are being
made to how layer groups operate then it may be beneficial to consider
the possibility of layer group settings like this for the future.

Nyall
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

olivier
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


Images intégrées 1

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Nyall Dawson



On 26 March 2014 11:07, Olivier Dalang <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Bernhard Ströbl
In reply to this post by olivier
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 development.
>
> Anyways, I'm very happy to know some improvements are in preparation !
>
>
> Kind regards,
>
> Olivier
>
>
> Images intégrées 1
>
>


__________ 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Régis Haubourg
In reply to this post by olivier
+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
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

olivier
In reply to this post by Bernhard Ströbl
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Anita Graser
In reply to this post by olivier
Am 26.03.2014, 01:07 Uhr, schrieb Olivier Dalang  
<[hidden email]>:

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

kimaidou
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 <[hidden email]>:
Am 26.03.2014, 01:07 Uhr, schrieb Olivier Dalang <[hidden email]>:

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Bernhard Ströbl
In reply to this post by olivier
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

olivier
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 1&2, 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

Images intégrées 1


_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Bernhard Ströbl
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 1&2, 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Régis Haubourg
In reply to this post by Martin Dobias
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
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Martin Dobias
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
<[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Régis Haubourg
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
<[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Cheers
Régis
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

ginetto
On 2 April 2014 11:55, Régis Haubourg <[hidden email]> wrote:
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Martin Dobias
In reply to this post by Régis Haubourg
Hi Régis

On Wed, Apr 2, 2014 at 11:55 AM, Régis Haubourg
<[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Régis Haubourg
Hi again,

> -----Message d'origine-----
> De : Martin Dobias [mailto:[hidden email]]
> 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#//006600000004000000
[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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Vienna hackfest: QGIS Legend discussion

Régis Haubourg
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
12