[Qgis-developer] Changing ergonomy of the visibility of layers inside groups ?

[DelazJ]

Hi,


2016-11-15 11:38 GMT+01:00 Nathan Woodrow <madmanwoo at gmail.com>:

> 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.
>
> Grey out is already used to indicate that a checked layer  is currently
out of its scale range of visibility (hence not visible). so it may be good
to keep greying layers when they "should" be visible but another option
makes them not rendered.

Harrissou

> 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
>
>
> _______________________________________________
> 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/2daa7c31/attachment.html>