On Fri, Oct 11, 2013 at 01:35:44PM +0200, Vincent Schut 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:
> >>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.) > > 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')? By 'radio-on-groups' I meant using radio behavior on groups rather than on layers. Having "selection type" as a parameter of a group solves the complexity problem I had in mind. --strk; _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
