<p dir="ltr">Hey Even,</p>
<p dir="ltr">Personally I think this is a good change and handy for the use case you mentioned.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Nathan </p>
<br><div class="gmail_quote"><div dir="ltr">On Tue, 15 Nov 2016 8:32 pm Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="gmail_msg">
<br class="gmail_msg">
I've been involved in discussions about improving/changing how visibility of<br class="gmail_msg">
layers (or groups) is handled when they are inside groups. Currently if you<br class="gmail_msg">
check/uncheck a group, this recursively checks/unchecks all its items (layers<br class="gmail_msg">
or sub-groups). There are workflows with large projects that include ~ 50<br class="gmail_msg">
layers in several groups and where users need to quicly turn on/off the<br class="gmail_msg">
visibility of groups, but when they don't want to change the visible of items<br class="gmail_msg">
inside the group. For those use cases, the layer themes functionnality has<br class="gmail_msg">
been tested but doesn't solve the need to be able to quickly (1 click) turn<br class="gmail_msg">
on/off/on/off the visibility of a group to be able to detect changes between<br class="gmail_msg">
raster imagery (the human eye is sensitive to movements more than colors), and<br class="gmail_msg">
they don't really have predefined configurations (would require creating tens of<br class="gmail_msg">
them)<br class="gmail_msg">
<br class="gmail_msg">
Basically what is proposed is the following:<br class="gmail_msg">
<br class="gmail_msg">
[ ] Group<br class="gmail_msg">
[x] Layer 1 --> Layer checked but group is not --> invisible<br class="gmail_msg">
[ ] Layer 2<br class="gmail_msg">
<br class="gmail_msg">
[x] Group<br class="gmail_msg">
[x] Layer 1 --> Layer checked and group too --> visible<br class="gmail_msg">
[ ] Layer 2<br class="gmail_msg">
<br class="gmail_msg">
There's a ticket <a href="https://hub.qgis.org/issues/14547" rel="noreferrer" class="gmail_msg" target="_blank">https://hub.qgis.org/issues/14547</a> about that.<br class="gmail_msg">
<br class="gmail_msg">
In the ticket it is suggested that the current behaviour might be preserved by<br class="gmail_msg">
using control-click. Control-click on a group would check/uncheck recursively<br class="gmail_msg">
all sub-items.<br class="gmail_msg">
<br class="gmail_msg">
One effect of this change is that there wouldn't be anymore a tri-state for a<br class="gmail_msg">
group. It is either checked or unchecked. One potential downside of the new<br class="gmail_msg">
behaviour would be that it might not be immediately obvious to determine the<br class="gmail_msg">
visibility of a layer if you have several levels of hiearchy : looking only at<br class="gmail_msg">
the layer item if it is checked isn't sufficient to tell about its visibility.<br class="gmail_msg">
Not sure if that's an issue though (and if so what could be ways of indicating<br class="gmail_msg">
the visibility state)<br class="gmail_msg">
<br class="gmail_msg">
At the API level, from what I can see,<br class="gmail_msg">
* Qt::CheckState QgsLayerTreeGroup::isVisible() would be renamed to bool<br class="gmail_msg">
isChecked() since it would be a binary state and not related to visibility.<br class="gmail_msg">
I'm not sure if there are users outside of the layer tree mechanism where we<br class="gmail_msg">
really need to want if a group is visible (ie all its subgroups and layers are<br class="gmail_msg">
visible ?). Wouldn't be hard to implement anyway<br class="gmail_msg">
* Qt::CheckState QgsLayerTreeLayer::isVisible() would be "split" into a bool<br class="gmail_msg">
isChecked() and a bool isVisible(). The later would inspect recursively its<br class="gmail_msg">
parents to figure out the final visibility state.<br class="gmail_msg">
<br class="gmail_msg">
Thoughts ?<br class="gmail_msg">
<br class="gmail_msg">
Even<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Spatialys - Geospatial professional services<br class="gmail_msg">
<a href="http://www.spatialys.com" rel="noreferrer" class="gmail_msg" target="_blank">http://www.spatialys.com</a><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Qgis-developer mailing list<br class="gmail_msg">
<a href="mailto:Qgis-developer@lists.osgeo.org" class="gmail_msg" target="_blank">Qgis-developer@lists.osgeo.org</a><br class="gmail_msg">
List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br class="gmail_msg">
Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>