[Qgis-developer] Reliable way to determine a groupIndex in the legend tree

Bernhard Ströbl bernhard.stroebl at jena.de
Fri Oct 11 02:35:12 PDT 2013



Am 11.10.2013 11:22, schrieb Sandro Santilli:
> On Fri, Oct 11, 2013 at 09:13:03AM +0000, Duarte Carreira wrote:
>> The group checkbox, imho, should *not always* switch children on/off. You should have a modifier to get this as a secondary behavior, like pressing the ctrl key when (un)checking the group checkbox. The primary behavior of the group switch should be to make the children invisible or visible, regardless of the children's visibility being on or off.
>>
>> In the primary behavior when the parent is turned OFF, the children are not drawn but retain their checked or uncheck status.
>> If you use the secondary behavior then unchecking the parent will uncheck the children. Same would apply when checking the parent on.
>
> Agreed, sounds like a sensible behavior to me.

The problem I see is that we have layers visible in the canvas that are 
unchecked, because their group is checked. Maybe an unchecked layer 
should show a partly checked state in that case.
>
> --strk;
>
>> De: aperi2007 [mailto:aperi2007 at gmail.com]
>> Enviada: quinta-feira, 10 de Outubro de 2013 12:59
>> Para: qgis-developer at lists.osgeo.org
>> Assunto: Re: [Qgis-developer] Reliable way to determine a groupIndex in the legend tree
>>
>> I guess instead that much better should be a group checkbox that enable/disable the under childs layer.
>>
>> This allow OFF the actual configuration or ON that same configuration.
>> Actually the group checkbox when checked put ON all the layer.
>> This often is mean too much information .
>>
>> Instead the mutual exclusive need to choose only one.
>> And in that case disable and ri-enable will reput the same original clayer.
>>
>> Andrea.
>>
>>
>> On 10/10/2013 10:08, Vincent Schut wrote:
>> On 10/09/2013 11:41 PM, Nyall Dawson wrote:
>>
>>
>>
>> Personally, I am also interested in enhancing group options in the layer
>> tree. Groups are not just stupid containers with only toggling of
>> visibility. They could also have a group opacity and blending and group
>> metadata. Later on we may also have clipping and masking on groups. So
>> we really should have an extensible mechanism for groups as new group
>> features appear.
>>
>> One thing I'd love to see is the ability to make the layers in a group "mutually exclusive". (ie, imagine radio buttons instead of checkboxes for controlling the visibility of layers within that group). I find I'm often going through a process of switching one layer on, then switching a bunch of other layers off for comparison purposes. A mutually exclusive layer group which automatically switched the other child layers off when I select a layer would make this process much nicer!
>>
>> +1 for this feature from a frequent user!
>>
>> Best,
>> Vincent.
>>
>>
>> Nyall
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Qgis-developer mailing list
>>
>> Qgis-developer at lists.osgeo.org<mailto:Qgis-developer at lists.osgeo.org>
>>
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Qgis-developer mailing list
>>
>> Qgis-developer at lists.osgeo.org<mailto:Qgis-developer at lists.osgeo.org>
>>
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>


__________ Information from ESET Mail Security, version of virus signature database 8904 (20131011) __________

The message was checked by ESET Mail Security.
http://www.eset.com




More information about the Qgis-developer mailing list