Opened 12 years ago
Closed 6 years ago
#9190 closed bug (fixed)
[BListView] multi-selection not preserved when DnD'ing
Reported by: | ttcoder | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/Interface Kit | Version: | R1/alpha4.1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Drag'n'drop interacts badly with multi-selection; so in essence, one has to DnD items one by one instead of being able to DnD all of your selection at once.
Steps:
- find a BListView populated with several items and which supports DnD.
- select a bunch of items (holding down shift).
- drag'n'drop the selected bloc (taking care to click _inside_ the selected bloc, not on an unselected item outside of it of course).
Expected results:
- the items should be dragged "en masse".
Actual result:
- just before the DnD session is started, the multiple selection is cancelled and only the one item below the mouse pointer is selected, instead. This results in dragging only one of the (previously selected) items. That is, unless you held down the option key.
Playing with it I've found the code actually requires holding down the option / cmd key, not just when multi-selecting but also during the actual DnD session; if you do this, it will preserve the selection and let you DnD all of the selection as intended. This is something of a regression from BeOS, which did not require hodling down a key, which was more intuitive... With this new state of affair we might get some support calls from clients who don't figure it out :-)
Did not look into a patch, but I suppose selection is handled in MouseDown() whereas it should be handled in MouseUp() or MouseMoved(): in MouseDown() it's too soon to to determine if the user is starting a DnD or just cancelling the selection.
(this bug -- or is it an enhancement? -- has been there a while, and is still there in alpha4.1)
Change History (14)
comment:1 by , 12 years ago
Summary: | [BTextView] multi-selection not preserved when DnD'ing → [BListView] multi-selection not preserved when DnD'ing |
---|
comment:2 by , 12 years ago
Type: | enhancement → bug |
---|
comment:3 by , 8 years ago
comment:4 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 7 years ago
I'm planning to look into this ticket for my next Haiku contribution. I confirmed it is still reproducible in recent builds. If there is any reason I should not do so or the ticket is invalid in some way, please let me know.
comment:7 by , 6 years ago
Patch here: https://review.haiku-os.org/c/haiku/+/299
The comment summary was correct, the selection behavior needed to be in MouseUp instead of MouseDown.
In working on fixing the multi-select drag and drop behavior, I noticed that the BListView allows double-click from a non-primary mouse button. It also allows drag and drop from a non-primary mouse button. In my experience with OSes, the secondary mouse button is used for context menus so I found this wrong and changed it. I don't think you should be able to double-click or dragNdrop with the secondary or tertiary mouse buttons.
follow-up: 9 comment:8 by , 6 years ago
I don't think you should be able to double-click or dragNdrop with the secondary or tertiary mouse buttons.
WRT drag'n'dropping with 2nd mouse button, there are applications for it: e.g. in Tracker it provides a context menu on drop to choose between copying, moving, or symlinking. So, quite useful. Or isn't that what you're talking about?
comment:9 by , 6 years ago
Replying to humdinger:
WRT drag'n'dropping with 2nd mouse button, there are applications for it: e.g. in Tracker it provides a context menu on drop to choose between copying, moving, or symlinking. So, quite useful. Or isn't that what you're talking about?
Ah, I did not realize you could do that in Tracker. I still find it very awkward, half the time I try to drag I end up doing the full right-click and get the context menu instead of initiating a drag. So to me it is perhaps not so useful.
Nonetheless obviously I don't want to break existing applications, especially Tracker, so I can remove the mouse button checking code from patch.
comment:11 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
After updating to a hrev after the merge, I have to say it feels quite weird...
Haveing a list item selected on MouseUp() instead of MouseDown() is strange. You think, "hey, I click, but nothing happens". Then you release the mouse button and think, "ah, so it did work... was it just unresponsive? Impossible, this is Haiku!? :)".
I'm afraid we need another solution for the original issue...
Just ran into the same issue with BurnItNow. Still an issue... Easily reproducible e.g. with Locale prefs' preferred languages and MediaPlayer's playlist.