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

[Matthias Kuhn]

Sounds good to me.

On 11/15/2016 11:34 AM, Even Rouault wrote:

> One effect of this change is that there wouldn't be anymore a tri-state for a 
> group. It is either checked or unchecked.

The visualisation could still be tri-state, I think

* Unchecked
* Checked (All subitems checked)
* Semi-checked (Checked but some sub-items are invisible)

Clicking would then switch between either Unchecked and Semi-Checked or
Unchecked and Checked depending on the subitems.

> 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.

The approach sounds good. What do you think about integrating on both
levels (group and layer) the methods isVisible() and
itemVisibilityChecked() methods? I think this API is more verbose than a
simple isChecked().

Matthias