QGIS » QGIS Application

Also #1808 relates to this issue, and will most probably be fixed.

Replying to [comment:1 homann]:

Also #1808 relates to this issue, and will most probably be fixed.

I mean #1637

Looks good.

Just a note: when dragging an item completely away (out of the window) it will be placed to the bottom. The dragging should be cancelled instead, I guess.

Even better would be to dump QTreeWidget and use QTreeView with a custom model. But that's probably too much work at once :-)

Martin

Good points Martin! Using QTreeView is a bit more work, I think. The look-n-feel is probably not dependant on which we use.

I like it, but it's better to use QTreeView in my opinion, too.
About the look&feel, don't worry, we can use a custom model or a delegate (or both).

Like it! as a couple of qgis users around here do.

Please consider also #1439, should be fixed also in this new gui.

I was able to test on the Mac using: 'qmake -project' then 'xcodebuild'. treewidget.app is available in the build directory to test.

I don't mind the defaults to bottom behavior when pulled to the side. This seems the quickest way to make something last in the legend queue, so this will be handy. On the Mac, the window will not autoscroll when you drag an item to the top or bottom of a window that has a drag bar/scroll widget (all items not displayed in the window). This is the intuitive behavior for the OS. With a scroll mouse, you can scroll and continue dragging an item, but the scroll should occur automatically when you reach the top or bottom of the tree being viewed.

It would also be good if groups auto-expanded after a delay of a second or so. Currently, you drop an item on a group and release the item, then the group opens. This item has to be moved to the correct position within the group.

Overall, this looks like a great improvement, especially if things will no longer jump and reorder themselves.

and what about multiple layer selection? we actually miss it in the standard legend.

The autoscroll is in planning, the one-liner I tried almost worked... :-)

Auto-expansion I don't know. Neat, but requires timers (or switch from QTreeWidget to ...). Good if.

Selecting multiple layers is easy. The hard part is to decided what can be done with two vector layers and a group in the same selection, or with a layer a symbol item, a file group and a file item...

Lutra, can you come up with some use cases and expected behaviour?

Okay, I added scrolling in 2cb735bf (SVN r11238). Only tested on Ubuntu. Let me know how it works on toher OS:es.

Replying to [comment:9 homann]:

Selecting multiple layers is easy. The hard part is to decided what can be done with two vector layers and a group in the same selection, or with a layer a symbol item, a file group and a file item...

Lutra, can you come up with some use cases and expected behaviour

Hi,

I understand that multiple selection introduces complications, but it would be enough just to use multiple selection to remove/unselect multiple layers/groups from the legend/project at one time (not always all I want to unselect/delete is in the same group and sometimes what I want to unselect/delete is in different groups), and regardless if I'm selecting a layer, a group, etc. To start, when selecting multiple layers all the other actions should be disabled, at least until when it will be possible to implement others safely.

This is one of that details that other gis software users do immediately notice in qgis.

Scrolling works fine! but I tested also just under Ubuntu 9.04

Replying to [comment:10 homann]:

Okay, I added scrolling in 2cb735bf (SVN r11238). Only tested on Ubuntu. Let me know how it works on toher OS:es.

Hi,

I noticed that #1568 is still valid in the latest revision. As this patch applies to qgslegend.cpp, you may want to consider including it in your latest developments.

Maybe, but it clashes with the fact that some people don't want symbology lines to be selectable (because they can't be moved).

Replying to [comment:13 homann]:

Maybe, but it clashes with the fact that some people don't want symbology lines to be selectable (because they can't be moved).

well, I guess if that symbology lines (and 'Files' title) will not be selectable, the problem will be fixed naturally. Am I wrong?

Replying to [comment:14 lutra]:

Replying to [comment:13 homann]:

Maybe, but it clashes with the fact that some people don't want symbology lines to be selectable (because they can't be moved).

well, I guess if that symbology lines (and 'Files' title) will not be selectable, the problem will be fixed naturally. Am I wrong?

That is the case for me on OS X: the symbology breakdown items are not selectable. This is very nice work, and it seems to be doing fine on this OS. Thanks!

Replying to [comment:11 lutra]:

it would be enough just to use multiple selection to remove/unselect multiple layers/groups
from the legend/project at one time

Second that!

Replying to [comment:14 lutra]:

Replying to [comment:13 homann]:

Maybe, but it clashes with the fact that some people don't want symbology lines to be selectable (because they can't be moved).

well, I guess if that symbology lines (and 'Files' title) will not be selectable, the problem will be fixed naturally. Am I wrong?

Well, there is functionality to drag and drop the "Files" and the files below it. At least that's my understanding of the code, but I have no idea how it is supposed to work.

And if you should be able to drag and drop, they must be selectable.

Needs more thinking.

Replying to [comment:17 homann]:

Well, there is functionality to drag and drop the "Files" and the files below it. At least that's my understanding of the code, but I have no idea how it is supposed to work.

And if you should be able to drag and drop, they must be selectable.

Right.

but as you I am not really sure about what drag and drop of the file name should do. But I recall clearly that dragging and dropping the file name above "files" crashed qgis, and this was resolved only recently, just a few days away.

If it was a necessary feature I guess should have been resolved a long time ago, so my guess is that is not necessary at all. But I may be wrong so I'll check it.

But the most important thing is that in any case seems that selecting "files" or the symbology have no function at all, so if this feature will be disabled, #1568 should be fixed naturally, otherwise I guess that #1568 patch still need to be applied.

Well, there is functionality to drag and drop the "Files" and the files below it. At least that's my understanding of the code, but I have no idea how it is supposed to work.

And if you should be able to drag and drop, they must be selectable.

Needs more thinking.

Hi homann,

I still see no use for selecting/dragging "files" and the file name below, dragging "files" is in any case forbidden (I can see it from the mouse pointer symbol if you try to do it), while, as already said, dragging the file name was source of big problems so it should really have no meaning at all.

Avoiding the selection of "files" and the file name below is a solution, this would allow automatically to close #1568 as not necessary anymore.

Meanwhile I'll ask if the patch available in #1568 is still good for the new legend gui, I haven't tested it and maybe resolves the #1568 problem without avoiding the selection of "files" and the file name below.

In any case I guess that this ticket could be closed: the new legend GUI is in place, and we can underline the idea of the necessity of multi layer selection in the legend in the proper ticket #1413