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

Denis Rouzaud denis.rouzaud at gmail.com
Wed Nov 16 05:44:37 PST 2016

Hi all,

Jumping in... Quite reluctant at first, I think it's indeed a very nice

Matthias' idea is quite nice and turns off my concerns.

I would prefer first approach (switching brtween partial and checked or
unchecked) as I find it more intuitive and also more practical: one
click only (I often switch on and off to make features blink).

Does our LayerTreeMaster (aka Martin) has some concerns for this change?


On 11/16/2016 02:05 PM, Matthias Kuhn wrote:
> On 11/16/2016 01:54 PM, Even Rouault wrote:
>>> 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.
>> That might work indeed. It is just hard to imagine what is the more natural 
>> way of handling this. I couldn't find something similar in other applications
>> Let me think out loud to a scenario :-)
> Another scenario would be:
> When clicking, the group toggle between unchecked, partially checked,
> checked. At the same time it caches the state for all subitems to
> restore the partially checked state when switching to this.
> At any time, when a subitems check state is changed, all parents
> invalidate their cached states and override it with the new partial
> check state. If the last remaining unchecked item is checked (and vice
> versa) clicking the group skips the partially checked state...
> Maybe that would be more natural?
>>> The approach sounds good. What do you think about integrating on both
>>> levels (group and layer) the methods isVisible() and
>>> itemVisibilityChecked() methods?
>> If we allow isVisible() for groups, it would need to be 3 state : 
>> TotallyVisible, PartiallyVisible, Invisible (probably better than using the 
>> Checked semantics directly, so we can decorrelate from how we render partial 
>> visibility)
> _______________________________________________
> 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/20161116/5ae12db6/attachment-0001.html>

More information about the Qgis-developer mailing list