[Qgis-developer] Changing ergonomy of the visibility of layers inside groups ?
Nathan Woodrow
madmanwoo at gmail.com
Tue Nov 15 02:38:25 PST 2016
Hey Even,
Personally I think this is a good change and handy for the use case you
mentioned.
To solve the UX of knowing if the layer is visible in a heavy nested list I
think we could grey out, or some kind of icon, for all layers not currently
on.
Nathan
On Tue, 15 Nov 2016 8:32 pm Even Rouault <even.rouault at spatialys.com> wrote:
> Hi,
>
> I've been involved in discussions about improving/changing how visibility
> of
> layers (or groups) is handled when they are inside groups. Currently if you
> check/uncheck a group, this recursively checks/unchecks all its items
> (layers
> or sub-groups). There are workflows with large projects that include ~ 50
> layers in several groups and where users need to quicly turn on/off the
> visibility of groups, but when they don't want to change the visible of
> items
> inside the group. For those use cases, the layer themes functionnality has
> been tested but doesn't solve the need to be able to quickly (1 click) turn
> on/off/on/off the visibility of a group to be able to detect changes
> between
> raster imagery (the human eye is sensitive to movements more than colors),
> and
> they don't really have predefined configurations (would require creating
> tens of
> them)
>
> Basically what is proposed is the following:
>
> [ ] Group
> [x] Layer 1 --> Layer checked but group is not --> invisible
> [ ] Layer 2
>
> [x] Group
> [x] Layer 1 --> Layer checked and group too --> visible
> [ ] Layer 2
>
> There's a ticket https://hub.qgis.org/issues/14547 about that.
>
> In the ticket it is suggested that the current behaviour might be
> preserved by
> using control-click. Control-click on a group would check/uncheck
> recursively
> all sub-items.
>
> One effect of this change is that there wouldn't be anymore a tri-state
> for a
> group. It is either checked or unchecked. One potential downside of the new
> behaviour would be that it might not be immediately obvious to determine
> the
> visibility of a layer if you have several levels of hiearchy : looking
> only at
> the layer item if it is checked isn't sufficient to tell about its
> visibility.
> Not sure if that's an issue though (and if so what could be ways of
> indicating
> the visibility state)
>
> At the API level, from what I can see,
> * Qt::CheckState QgsLayerTreeGroup::isVisible() would be renamed to bool
> isChecked() since it would be a binary state and not related to visibility.
> I'm not sure if there are users outside of the layer tree mechanism where
> we
> really need to want if a group is visible (ie all its subgroups and layers
> are
> visible ?). Wouldn't be hard to implement anyway
> * Qt::CheckState QgsLayerTreeLayer::isVisible() would be "split" into a
> bool
> isChecked() and a bool isVisible(). The later would inspect recursively its
> parents to figure out the final visibility state.
>
> Thoughts ?
>
> Even
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20161115/944eb9f6/attachment.html>
More information about the Qgis-developer
mailing list