QGIS » QGIS Application

I think this would be more complex than average uses could bear

I find the lack of nested groups in projects with lots of layers to be a significant shortfall, especially when using QGIS to explain something to observers... I'm continually hunting for the correct layers to turn on and off.
Nesting is the same model that everyone uses with directories to handle this complexity so should be intuitive for most users.

I agree,
I feel the same necessity for a more complex legend structure and the same is asked by the vast majority of the users that approach QGIS. Together with the lack of multiple selection of layers in the legend and with the lack of an option to "add as group" when adding vectors/rasters (tickets already exist for both issues), is one of more important tasks to be accomplished to improve qgis usability.

Meanwhile I'll add this ticket to the list of the ones possibly to be discussed in the next developer meeting.

Replying to [comment:3 Donkagen2]:

I find the lack of nested groups in projects with lots of layers to be a significant shortfall, especially when using QGIS to explain something to observers... I'm continually hunting for the correct layers to turn on and off.
Nesting is the same model that everyone uses with directories to handle this complexity so should be intuitive for most users.

The patch also contains support for nested layers in the QGIS mapserver. Please review.

Thank you Jürgen, for providing this patch!

I had a brief test (only the desktop), not the QGIS mapserver. It seems to work fine. There is one usability issue, though: if you want to add a new group to an already selected group (potentially deeply nested), the newly added group is always added to the very bottom. It would be nice if the newly added group would be added to the currently active (selected) group, not to the very bottom. I don't know how complicated this would be to fix?

Should I report this as a separate issue? It is not directly related to the nested grouping patch, but the issue already existed before.

Further testing revealed another, more serious issue:

when removing the parent group of a nested group (e.g. 2 other groups nested within a parent) with a right-click "Remove", QGIS hangs/crashes.

This happens on Ubuntu Lucid 64bit with QT 4.6.2

Replying to [comment:9 neumann]:

when removing the parent group of a nested group (e.g. 2 other groups nested within a parent) with a right-click "Remove", QGIS hangs/crashes.

fixed in the new patch.

Replying to [comment:8 neumann]:

Thank you Jürgen, for providing this patch!

np.

I had a brief test (only the desktop), not the QGIS mapserver. It seems to work fine. There is one usability issue, though: if you want to add a new group to an already selected group (potentially deeply nested), the newly added group is always added to the very bottom. It would be nice if the newly added group would be added to the currently active (selected) group, not to the very bottom. I don't know how complicated this would be to fix?

added in the new update of the patch.

I can confirm that adding new groups directly as a sublayer seems to work now.

Also, removing whole groups recursively seems to work fine now.

Thanks a lot!

yes, I also tested the patch and it really looks great!

I opened a enhancement ticket (#3026), now that we (will) have nested groups and multiple selection: drag and drop of multiple selection of layers/groups should move the entire selection. Now it moves just one layer/group.

Having nested groups is a very cool feature.

In the patch, there is a bug with the mapserver if there are nested groups and we do a request with the name of a nested group (e.g. LAYERS=nested_group). It works for toplevel groups and single layers.

Replying to [comment:15 mhugent]:

Having nested groups is a very cool feature.

In the patch, there is a bug with the mapserver if there are nested groups and we do a request with the name of a nested group (e.g. LAYERS=nested_group). It works for toplevel groups and single layers.

Oh, I didn't notice that groups are "named layers". Is that intentional?

New patch also allows multiple layers to be moved (layers are hidden while the move is in progress).

In WMS groups are now nameless (not sure if that's bad - groups in UMN mapserver are nameless too).

Also it contains a change that disables the ability to query layers in editing mode. For one on shape files setting a query make (some?) OGR layers read-only, but also for other layers it might be irritating or even break things, if you have edited features, that later are filtered away (see also #2951).

Yes, it's intentional that groups are named layers. Because it is very convenient to refer to groups with a single WMS layer name.

Replying to [comment:18 mhugent]:

Yes, it's intentional that groups are named layers. Because it is very convenient to refer to groups with a single WMS layer name.

groups should now be named again and get the CRSes and bbox.

applied in 0c5ebf7c (SVN r14395).

Thanks, very nice and useful feature!

Let me suggest a little improvement:

If I check (set visible=yes) a group of layers, all layers/groups inside it will become visible, and viceversa. Is this correct? I think that only the previous checked layers/groups inside that group have to become visible, the others must remain unchecked. Think about groups with lot of layers and nested groups: if I check the root group... all will become visible... I think this is not correct/useful.

michele

Unsure: to me the current behaviour seems correct

Thanks, the nested groups are great.

Personally I think the behaviour suggested by Michele is more useful and more intuitive. It is also the standard behaviour in other applications like Mapinfo.

When a group is turned off in Mapinfo the checkboxes (in the layer control) for layers/groups inside it keep their state (i.e. if they were checked they stay checked). I think this is probably the best behaviour... although I guess they could also be greyed-out in the layer control.