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