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