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

[Duarte Carreira]

Etienne,

I was not opposing your idea. Just proposing a default behavior for the group/children visibility pattern.

I sometimes do have need for your use case. Maybe there could be an option in the context menu when right-clicking a layer - eg "Mutually exclusive layers". A popup window could appear that allows you to select the 2 "opposing" collections of layers, and then these could appear with a radio button in the maplegend.

Duarte

De: Etienne Tourigny [mailto:etourigny.dev at gmail.com]
Enviada: sexta-feira, 11 de Outubro de 2013 19:52
Para: Vincent Schut
Cc: qgis-developer
Assunto: Re: [Qgis-developer] Reliable way to determine a groupIndex in the legend tree



On Fri, Oct 11, 2013 at 8:35 AM, Vincent Schut <schut at sarvision.nl<mailto:schut at sarvision.nl>> wrote:
On 10/11/13 11:48, Sandro Santilli wrote:
On Fri, Oct 11, 2013 at 09:33:05AM +0000, Andreas Neumann wrote:
Am 11.10.2013 09: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.

Yes, a sensible behavior.

But there is still use-case for the radio-button like behaviour. Imagine
having a group with a series of orthoimages of different years and you
quickly want to see each year. In this case, the radio-button behaviour
would save you one click. So I don't think that this contradicts the
other proposal listed above here.

Maybe this could be obtained with secondary behavior (SHIFT-click) on layers,
but it sounds like something that easily becomes confusing (conflicting
with radio-on-groups, undefined behavior for unchecking etc.).

switching between several raster layers is exactly the main (only) use I have for this, and as we are mainly doing remote sensing stuff here, including lots of time series, it is something I really frequently miss. (Practical example: you have several Landsat rasters from different times for the same area, all of them have clouds but not in the same place. By switching between layers, you can easily get a 'cloudfree' view of the entire area.)

I have made the Loop Visible Layers plugin for just that. Add the reaster layers you want to see in a group, then select that group in the Loop Visible Layers dock and click play. You will see those raster layers one at a time.

IMHO 'undefined behavior for unchecking' should not be a problem; usually unchecking simply is disabled for radio groups. I do not know any UI with radio groups where you can uncheck a selected item by clicking it again... I think having it as a secondary behaviour is just confusing. I'd rather see groups have a 'selection type' property, which defines the selection behaviour within that group (and on that level only). Could you explain what you mean with 'conflicting with radio-on-groups' (what are 'radio-on-groups')?


Vincent.


--strk;

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20131014/2b2f0917/attachment-0001.html>