Conversation
|
This would be a really nice feature to have, and it looks like the PR is all ready to go - is there anything stopping it from being merged? |
adds a drag data get handler, and adds the file:// URIs of the current selection to it. there are still some rough edges.
recommended column length for commit message is 72 chars.
see comment in below link cboxdoerfer#11 (comment)
g_string_free needs to be used for GStrings, g_free was used earlier
5f2a235 to
5d46d39
Compare
|
@ladybunne please check #11 for the discusssion (its a really old issue so scroll to the end) |
|
Noted! Just read through, looks like things are promising for this feature, at last. 🙏 |
|
Awesome, thanks for the PR. I'm testing it right now and will be reporting back to you! |
|
I'm resolving your comments as we speak but in the meantime, what do you think about this and rubber-band selection conflicting for the drag action? Is the current behaviour intuitive? Ctrl+click+drag without releasing ctrl for the last item is the current implicit behaviour. Should some of the event handlers be tweaked to make this more intuitive? Edit: ctrl or shift, whatever Edit: Right now, the moment you do the first drag, you cannot do a rubber-band after that. I assume this is not ideal. |
c42ad07 to
e9a2905
Compare
1. Use db_..._for_each instead of getting indices and passing that and... 2. Use g_clear_pointer 3. Assorted formatting and style fixes
e9a2905 to
eb09e0b
Compare
|
@porridgewithraisins thanks for the update, I'm having a look at the changes. Regarding the issue with rubber-band selections. Ideally the approach that (at least to me) feels most intuitive, is by choosing rubber-band selection or drag action depending on whether the item that registered the click was already selected or not. So if you click on an item that's already selected and move the mouse we start drag mode and if the item wasn't selected we start rubber-band selection. However I think this would only work well if we switched from updating the selection etc. on button-press events to button-release events. Because right now as soon as you click on an item the selection gets reset and hence there would be no way to drag multiple selected files. So unless I'm missing something, unfortunately this doesn't work. So another solution I'd be OK with, is by having a dedicated area to start rubber-band selection (e.g. a small gap on the right or left side (depending on whether RTL or LTR text mode is enabled)) or drag actions (e.g. the file icon). I'll try to find some other applications which have to deal with this issue and see how they avoided it, so we can get this at least somewhat consistent with others. Modifiers might be fine as well, but preferably I'd like get it to work without the need for them. |
|
Agreed in general.
Actually right now there is a way to drag multiple items. Here's how: Click on item 1, ctrl+click on item 2, and without releasing the mouse after the 2nd click, start dragging. The same works with shifts in between. This is obviously un-intuitive and needs to change, but knowing this may help with figuring out what to tweak to get it working right. I'll send a GIF later tonight. |
remove useless accumulator as well
|
@cboxdoerfer this is how multiple item dragging works right now: Video_2025-08-26_13-56-30.mp4I suppose, like you said, what we should do is make it so that click selects only on release? that way the drag event will take precedence unless they release? |
|
@cboxdoerfer any reason why this was never merged? I miss this feature badly from Everything |
No description provided.