! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Of multiple selected files only the last selected is opened
Status:
RESOLVED: FIXED

Comments

Description Mathias Brodala 2006-11-01 21:15:28 CET
User-Agent:       Opera/9.02 (X11; Linux i686; U; de)
Build Identifier: 

If you select multiple files via [Shift] and press [Enter], only the last selected file is opened with the associated application.

Reproducible: Always

Steps to Reproduce:
1. Select multiple files.
2. Press [Enter].

Actual Results:  
Only the last file is opened.

Expected Results:  
All files should be opened in their application.
Comment 1 Benedikt Meurer editbugs 2006-11-03 15:22:59 CET
Hm, this is the expected behavior. Dunno if that should be changed.
Comment 2 Mathias Brodala 2006-11-03 15:25:04 CET
> Hm, this is the expected behavior.

Really? For me it is pretty unexpected as it would make no sense for me anyway to select multiple files but open only the last one.
Comment 3 Benedikt Meurer editbugs 2006-11-03 15:31:29 CET
Pressing "Enter" on the cursor item/row is the same as double-clicking the item/row. It's even the same signal in GTK+: "item-activated"/"row-activated". And the signal is passed exactly one item/row (the cursor item/row). Because of this fact, it is the expected behavior for atleast all GTK+ applications, and IIRC that's the same for other toolkits.
Comment 4 Mathias Brodala 2006-11-03 15:40:18 CET
> […] Because of this fact, it is the expected behavior for atleast all GTK+ applications, and IIRC that's the same for other toolkits.

I actually never saw an application behaving the way Thunar does. Take Nautilus for example (Yeah, I know you are sick of comparisions with it.). Select multiple files or directories and press enter and voilá: everything is opened as expected (at least by me).

Or Konqueror for example: selecting multiple directories and pressing [Enter] opens another directory (don’t ask me why). But selecting „Open in new window“ opens each directory in a new window. The same for files.

I don’t know a reason somebody would be bothered if you changed Thunar’s behaviour the way I expect it to be. How about you?
Comment 5 Benedikt Meurer editbugs 2006-11-03 16:45:37 CET
Have to check this again. Bug definitely depends on bug #2454.
Comment 6 Benedikt Meurer editbugs 2006-11-03 16:46:17 CET
Ups, wrong bug report... ;-)
Comment 7 Benedikt Meurer editbugs 2006-11-04 19:48:34 CET
Moving to 1.0.0final.
Comment 8 Benedikt Meurer editbugs 2006-11-12 18:01:44 CET
*** Bug 2568 has been marked as a duplicate of this bug. ***
Comment 9 Benedikt Meurer editbugs 2006-11-13 11:47:16 CET
Created attachment 874 
Possible fix

Something like this?
Comment 10 Mathias Brodala 2006-11-13 17:00:10 CET
> Something like this?

Not really. Now nothing happens at all instead of opening the last file/dir.
Comment 11 Lionel Le Folgoc 2011-03-29 21:04:29 CEST
*** Bug 5943 has been marked as a duplicate of this bug. ***
Comment 12 Lionel Le Folgoc 2012-02-14 18:02:26 CET
*** Bug 7841 has been marked as a duplicate of this bug. ***
Comment 13 Nick Schermer editbugs 2012-09-30 08:45:46 CEST
Handled by GIO now and works fine here.
Comment 14 mikkl 2013-03-26 12:21:37 CET
Sorry to post this to a closed bug report, but for me the issue is still present today (thunar-1.6.2). I can only open all of the selected files when using right-click -> action, pressing 'enter' on the selection only opens the last selected one. Is there something one could miss so that this feature gets disabled?
Comment 15 Mathias Brodala 2013-03-26 19:18:11 CET
(In reply to comment #14)
> Sorry to post this to a closed bug report, but for me the issue is still
> present today (thunar-1.6.2). I can only open all of the selected files when
> using right-click -> action, pressing 'enter' on the selection only opens
> the last selected one. Is there something one could miss so that this
> feature gets disabled?

Confirmed. After selecting multiple files and pressing the Enter key, the selection is reduced to the last file and only that one is opened.
Comment 16 mikkl 2013-03-27 23:18:16 CET
Hmm, I also noticed: The issue corresponds only to the "View as detailed list". If one has selected one of the other 2 views (View as icons, View as compact list) then the behaviour is similar, but different. Here, none of the selected items will be opened when pressing 'Enter'. Instead, the last *single* selected item, which may not be in the selection at all, will be opened.

E.g. there's a folder with items 1..20..
Select only item number 3.
Then select items number 11-14.
Hit enter.
=> Item number 3 will be opened

This only happens when selecting the items with a mouse! If you do it with your keyboard (shift + arrow keys) then it will be like in detailed list view (last item in list will be opened). Seems like it's still the case like in "comment #3", where Benedikt mentioned that only the active row is considered.
Comment 17 Helder 2015-01-04 17:07:59 CET
The bug still happens on Thunar 1.6.3:
1. Go to a folder with files A, B, C and D
2. Press CTRL and click A, C and D
3. Press ENTER

Actual result
File D is opened

Expected result
Files A, C and D are opened.

This is particularly anoying when carefully selecting a long list of musics to play and then realising our selection is lost when pressing ENTER =/
Comment 18 Steve Dodier-Lazaro editbugs 2015-02-09 16:08:03 CET
Input events could be handled by the files/folders' container to detect and process multiple files. I don't think we have time to fix this for 4.12 but the user experience right now is a bit inconsistent, and also the cost of realising that only the last file will be opened is high, as pointed out in the previous comment.

I would suggest that Enter on multiple files opens them all (grouping them by filetype handler and sending all similarly-handled files at once to an app). Ctrl+Enter, Ctrl+Double click and Ctrl+Double middle click also need to be defined.
Comment 19 Andre Miranda editbugs 2017-08-09 23:46:17 CEST
*** Bug 13767 has been marked as a duplicate of this bug. ***
Comment 20 Cristian Gómez 2018-10-18 17:51:18 CEST
I would also love to have the behaviuor of open all selected files at once. One use case could be that you have several PDF files you want to read all at once, this will be handy in that case
Comment 21 Goran 2019-05-18 18:40:22 CEST
Present in 1.8.5.
From the terminal, running
thunar path1 path2 ...
opens all of the given paths (directories or files), so for consistency it should be doing the same when using the graphical interface.
Comment 22 groucho 2019-05-19 20:47:21 CEST
I have always been confused by this.
Also, I am not sure if it is a gtk3 issue, but I have tried different gtk themes and none of them highlight the "selected item".
It is impossible to know which item will be opened.

Ctrl+O seems to do the action that I am expecting when I am hitting the Return key in a file explorer.

Could it be possible to merge Ctrl+O and Return into the same action?
Comment 23 Theo Linkspfeifer editbugs 2019-06-16 14:54:09 CEST
Where should this be fixed? Thunar or exo?

https://git.xfce.org/xfce/exo/tree/exo/exo-icon-view.c#n1308
Comment 24 alexxcons editbugs 2019-06-17 10:55:14 CEST
Not sure if it can be fixed in exo alone (would suprisme me).
If so, IMO it would be ideal to get fixed in exo.
But my guess would be, that the major part of the fix will be in thunar.
Comment 25 Reuben Green editbugs 2020-02-14 23:31:21 CET
Created attachment 9454 
patch to allow multiple file selections to be opened via the keyboard

I have not yet tried to fix details view, as this works somewhat differently, and I wanted to get an idea of whether what I've done with this patch is the right approach before trying to do that. If people like this patch then I'll have a go at fixing details view.

The behaviour implemented by this patch is as follows. If you select multiple files and then press enter, space, or Ctrl^O, all of the files are opened. If you double-click (or single-click in single-click-to-activate mode) on any of the files in a multiple selection, then the selection is changed to just that file and it is opened, unless you are holding down Control, in which case the whole selection is opened. This all works however you selected the multiple files (control, shift, or rubber band).

I have noticed one small annoyance with my fix: if you select multiple files, hold down Control, and double click one of them, then all of the selected files are opened as desired, but the one you clicked on is very briefly de-selected then re-selected. However, I don't think this is a serious problem, it just looks a bit bad, and I cannot see any easy way to stop it.

I think that this fix is the best I can manage without making changes in exo. This fix is the best work-around I can think of for the (I think) rather strange design of the GtkIconView widget (and this design is maintained in exo-icon-view), which seems not to be well-suited for multiple selection mode. For example, there is no keybinding signal to activate all selected items: there is only a signal to activate the "cursor item", and my patch abuses this signal and the related "item-activate" signal to fix the bug. This fix is a bit of a hack but I can't see a better way to do it without changing exo. I am currently working on a patch for exo to make multiple selection mode more usable (at least, more useable in my opinion!). Do any other Xfce programs use exo-icon-view in multiple selection mode? If no-one else uses it then it should be OK to change it, but if someone else is using it then I will need to check that I don't break anything for them.

Anyway, sorry for the long comment. Criticisms and suggestions for improvement are very welcome!
Comment 26 Reuben Green editbugs 2020-02-14 23:34:16 CET
[bugzilla cut off the first paragraph of my previous comment. here it is]

So I think I have managed to fix this for icon view and compact view. I think that the behaviour I have
implemented here is what most users would expect, at least for double-click-to-activate-mode (I think the
behaviour is also sensible in single-click-to-activate mode, but I don't use this mode myself so I don't have
much idea of what expected behaviour is in this mode).
Comment 27 alexxcons editbugs 2020-02-15 19:22:41 CET
Thanks alot for the patch, works well for me !

I would be fine with having the same patch for detailed view .. so guess I best wait to have both patches before pusing anything do dont get possible inconsist behaviour between views.

I would suggest to push both patches to the 4.14 branch and master. Later on, if you fixed exo and it got released, we still can modify thunar master accordingly. 

> Do any other Xfce programs use exo-icon-view in multiple selection mode?

Not that I know of. If you are going to change exo, it anyhow would result in a new exo version. So should be fine.
Comment 28 Reuben Green editbugs 2020-02-16 19:00:50 CET
Thanks Alex. I will start working on fixing the details view. It would probably be good if this bug was reassigned to me, but I don't think I can do that. Can anyone help?
Comment 29 Reuben Green editbugs 2020-02-18 15:20:39 CET
Created attachment 9473 
patch to allow multiple file selections to be opened via the keyboard

Here is a patch to fix this for all views (icon/compact and details). The fix for the icon/compact case is the same as the previous patch. The fix for the details view feels a like a bit of a hack, but I think it is necessary in order to work around some behaviour in gtk. Essentially, the patch adds a handler for the "select-cursor-row" event to allow opening selections via the keyboard. However, the default gtk handler for this (which gets called via ExoTreeView) always reduces any multiple selection to just the single "cursor item", and I cannot see a way to prevent this other than bypassing the default handler altogether.

I have found a problem with this fix (there may be more, of course!). In icon/compact view, selecting multiple files and then double clicking (in double-click-to-activate mode) anywhere in the selection while holding down control opens all of the files in the selection, while in details view it removes the clicked file from the selection and opens all of the others. This behaviour comes from exo (and probably ultimately from gtk) and I cannot see a good way of making details view behave like icon/compact view without putting lots of code into thunar that messes around with the internals of exo structures, and I think this will probably lead to lots of subtle bugs.

Thus I propose the we apply this fix to thunar for now, and I will see if I can come up with some changes to exo to ensure consistent behaviour in select-multiple mode. I realise that this patch will introduce inconsistent behaviour between icon/compact view and details view, but 
(a) I don't think I will be able to solve this in thunar alone
(b) I don't think opening multiple selected files via ctrl+click is a common use-case
(c) one can work around this by using return, space, or ctrl^O
(d) this patch is replacing a very big bug with a much smaller one.

Comments, criticisms, and suggestions for improvement are most welcome.
Comment 30 alexxcons editbugs 2020-02-20 00:03:39 CET
That patch looks good to me and works excellent !

I would not have found that small flaw for icon/compact view if you would not have mentioned it .. so I am pretty fine with that one :) ... as you said, a very fair tradeoff. 

The hackish nature of the details view patch is unpleasant, but ok for me to get that thing fixed. Would be nice to have a fix in exo for it.

So thanks alot for your contribution!  I'll just push it to master and 4.14.

Fix will be released in thunar 1.8.13
Comment 31 Git Bot editbugs 2020-02-20 00:05:30 CET
Reuben Green referenced this bugreport in commit 9801a67b3a165fc1be81b520ec28b5529a9ab822

Allow opening of multiple file selections (bug #2487)

https://git.xfce.org/xfce/thunar/commit?id=9801a67b3a165fc1be81b520ec28b5529a9ab822
Comment 32 Git Bot editbugs 2020-02-20 00:07:55 CET
Reuben Green referenced this bugreport in commit 5e58fd17f88476c9ad341e2236c5aead7e1444cd

Allow opening of multiple file selections (bug #2487)

https://git.xfce.org/xfce/thunar/commit?id=5e58fd17f88476c9ad341e2236c5aead7e1444cd
Comment 33 alexxcons editbugs 2020-02-22 17:33:41 CET
*** Bug 16384 has been marked as a duplicate of this bug. ***
Comment 34 alexxcons editbugs 2020-03-25 16:14:07 CET
Have to reopen this one, since there is a regression

I don't do much drag & drop, so I completely overlooked that one :/

In detailed/compact view, it is not possible any more to drag and drop multiple files at once.

Reuben, could you please take a look at it ?
Comment 35 Git Bot editbugs 2020-03-25 16:18:30 CET
Alexander Schwinn referenced this bugreport in commit 1b66c2a9ac4b21fb2386df88415eec5031fa9c36

Revert "Allow opening of multiple file selections (bug #2487)", because it introduced a regression (Not possible any more to DnD multiple files in icon/compact view)

https://git.xfce.org/xfce/thunar/commit?id=1b66c2a9ac4b21fb2386df88415eec5031fa9c36
Comment 36 alexxcons editbugs 2020-03-25 16:21:24 CET
^ reverted the commit on the 4.14 branch to release 1.8.14 without it.

I will keep the commit on master for now .. guess we will find a fix for the regression.
Comment 37 Reuben Green editbugs 2020-03-25 16:23:51 CET
Oh dear, I'm sorry for this. Yes, I will have a look and see what I can do. I clearly need to test my patches more.
Comment 38 Reuben Green editbugs 2020-03-27 17:05:18 CET
Created attachment 9642 
patch to fix regression

Here is (I think) a fix for this regression.

This patch removes a few lines of code that I added to fix an inconsistency in behaviour between icon/compact view and detailed view. The inconsistency was as follows. Suppose you have multiple files selected, and you single-click (i.e. click and release) on one of them (assuming you're in double-click-to-activate mode). In details view, all files except the one you clicked were unselected, but in icon or compact view, the file selection did not change.

Thus this patch puts this behaviour back to what it was before my previous patch.

If I recall correctly, I put these lines in my previous patch because I thought I had introduced this inconsistency with my fix for this bug. However, after some investigation I've found that this inconsistency was already present before my fix, so I should not have tried to fix it in the same commit.

Once again, sorry for the mistake.
Comment 39 Theo Linkspfeifer editbugs 2020-03-27 17:50:23 CET
Currently, all selected files are opened on button press. The correct behavior is to only open the clicked file and unselect the other ones (see xfdesktop and other GTK file managers).
Comment 40 Reuben Green editbugs 2020-03-27 19:08:01 CET
(In reply to Theo Linkspfeifer from comment #39)
> Currently, all selected files are opened on button press. The correct
> behavior is to only open the clicked file and unselect the other ones (see
> xfdesktop and other GTK file managers).

Thanks Theo!

Gah, clearly my testing skills are still bad!

Yes, now I think about it that was probably the reason I added those lines - my memory is terrible.

OK, so this might not be a quick fix after all. Back to the drawing board.
Comment 41 Reuben Green editbugs 2020-03-28 15:45:35 CET
So I have been looking around at other gtk file browsers to get some ideas on how other people deal with this, and I have not found any others that use GtkIconView like thunar does (well, thunar uses ExoIconView, but this is derived from GtkIconView). As far as I can tell from a quick look at the source code, nautilus, nemo, and caja all define their own custom widgets for this purpose. I also looked at xfdesktop, but xfdesktop also implements a custom widget rather than using ExoIconView/GtkIconView. Further, after a brief search via google, github, and gitlab, I have not been able to find any other applications that use GtkIconView in select multiple mode like thunar does. Thus I have no examples of how to get the desired behaviour to use as a starting point.

Can anyone point me to any code where GtkIconView is used in select multiple mode in a similar manner to what we have in thunar, and where they already have all the behaviours that we are trying to get working here? If anyone can, it would help me to get this working. Alternatively, if anyone with a deeper knowledge of gtk than me (and that is not a very strong condition at all :) ) can suggest a way this might be done, or even give a hint of where to start, that would help.

If not, I'll carry on tinkering with this myself, but I've no idea how easy/possible it will be to find a fix.

Thanks!
Comment 42 Theo Linkspfeifer editbugs 2020-03-29 13:20:09 CEST
Created attachment 9645 
quick diff

Here is a possible solution. Note that the details view code is still unchanged.
Comment 43 Reuben Green editbugs 2020-03-29 13:45:37 CEST
Created attachment 9646 
patch to fix regression

So here is a possible fix for this - I've made it by adapting the fix from details-view.

It seems to make everything work as we want it, but no doubt it introduces some other bug :)
Comment 44 Reuben Green editbugs 2020-03-29 13:46:11 CEST
Ah, sorry Theo, I didn't see your patch - I'll give it a test now
Comment 45 Reuben Green editbugs 2020-03-29 14:16:59 CEST
So there is a problem that is shared by both my fix and Theo's. If you select multiple file and then single-click one item in the selection, the selection remains unchanged, while it should change the selection to just the single-clicked file.
Comment 46 Reuben Green editbugs 2020-03-29 14:24:58 CEST
(In reply to Reuben Green from comment #45)
> So there is a problem that is shared by both my fix and Theo's. If you
> select multiple file and then single-click one item in the selection, the
> selection remains unchanged, while it should change the selection to just
> the single-clicked file.

... which is exactly the bug I mentioned in comment 41 as being already present in thunar and thus ok. I had completely forgotten I mentioned it. I think my brain is melting.
Comment 47 Reuben Green editbugs 2020-03-29 14:30:39 CEST
So as far as I can tell from some brief testing, Theo's fix and mine produce the same results. If I'm right about that, then I would vote for Theo's solution as it avoids messing around with stopping signals like mine does.
Comment 48 Theo Linkspfeifer editbugs 2020-03-30 13:07:21 CEST
> If you select multiple file and then single-click one item in the selection, the selection remains unchanged, while it should change the selection to just the single-clicked file.
This behavior is shared with xfdesktop.

Does your code fix details view also or is some change still needed?
Comment 49 alexxcons editbugs 2020-03-30 23:23:56 CEST
Thank you both for woring on that !

(In reply to Reuben Green from comment #46)
> (In reply to Reuben Green from comment #45)
> > So there is a problem that is shared by both my fix and Theo's. If you
> > select multiple file and then single-click one item in the selection, the
> > selection remains unchanged, while it should change the selection to just
> > the single-clicked file.
> 
> ... which is exactly the bug I mentioned in comment 41 as being already
> present in thunar and thus ok. I had completely forgotten I mentioned it. I
> think my brain is melting.
I just checked thunar 1.8.12 ... seem it is possible there to single click into the selection to select a single file. Or did you refer to something else ?
Comment 50 Reuben Green editbugs 2020-03-31 12:19:04 CEST
Alex - I checked out the parent commit of the commit implementing my fix (the fix was commit 	9801a67b3a165fc1be81b520ec28b5529a9ab822, and its parent was 90c226d8e2c4f18e1fc362773490b80aa22781d8) and found that single-clicking on a multiple selection did not reduce the selection to just the file clicked. So maybe this behaviour has been introduced in a commit between 1.8.12 and 90c226d8e2c4f18e1fc362773490b80aa22781d8?

Theo - sorry, I posted a flurry of comments that didn't make much sense. My point is that this behaviour (single click on a file in a multiple selection does not change the selection to just that file) was already present before my fix for this bug and so it is not a problem that our fixes both have this behaviour (so in particular what I said in comment 45 is wrong - I was having a stupid moment :) ).
Comment 51 alexxcons editbugs 2020-04-03 22:11:35 CEST
(In reply to Reuben Green from comment #50)
> Alex - I checked out the parent commit of the commit implementing my fix
> (the fix was commit 	9801a67b3a165fc1be81b520ec28b5529a9ab822, and its
> parent was 90c226d8e2c4f18e1fc362773490b80aa22781d8) and found that
> single-clicking on a multiple selection did not reduce the selection to just
> the file clicked. So maybe this behaviour has been introduced in a commit
> between 1.8.12 and 90c226d8e2c4f18e1fc362773490b80aa22781d8?
Sorry, you are right, looks like tested some wrong thunar-version (the one with your fix :D)

So the idea is to review & test Theo's diff ? And if it is fine, we push it and call it a day ?

(Possibly better I keep it master only .. bad experience with pushing more complex stuff to 4.14 :P)
Comment 52 Reuben Green editbugs 2020-04-03 22:50:43 CEST
(In reply to alexxcons from comment #51)
> So the idea is to review & test Theo's diff ? And if it is fine, we push it
> and call it a day ?

Yes, that would be my suggestion. I think Theo's fix is the better one because it is simpler than mine, and I cannot see any problems with it (unless using a variable as in Theo's fix might cause a race condition in a multi-threaded setting, but my knowledge of multi-threaded programming is basically zero, so I don't know). I have been using master patched with Theo's diff as my default thunar for a few days now, and I have not noticed any problems. It would be nice to fix the bug with a single click on a multiple selection as well, but I think that is not related to this issue (it seems to be a bug in exo) and in any case it was the behaviour before my fix so we have not introduced a new bug.

> (Possibly better I keep it master only .. bad experience with pushing more
> complex stuff to 4.14 :P)

That seems like the best plan to me. My guess is that multi-file selection is a very commonly used feature so anything that messes around with it needs careful testing.
Comment 53 alexxcons editbugs 2020-04-03 23:01:43 CEST
Ok ... I just tested https://bugzilla.xfce.org/attachment.cgi?id=9645 and took a look on the code.
Works fine for me,  thanks Theo !

> unless using a variable as in Theo's fix might cause a race condition in a multi-threaded setting
Afaik gtk GUI part runs rather linear .. there is some main loop which periodically does stuff.  There are some asyn actions in thunar, e.g. loading thumbnails .. though the most part is triggered from within the gtk main loop. So that should be no problem.

@Theo
Whats about that TODO in line 789 ?  I just took a try for removing that block .. seems like it does not have any consequence.
So I guess the whole method can be removed ... I would do that in an separate commit. Would that be fine for you ?
Comment 54 alexxcons editbugs 2020-04-06 23:22:48 CEST
(In reply to alexxcons from comment #53)
> Ok ... I just tested https://bugzilla.xfce.org/attachment.cgi?id=9645 and
> took a look on the code.
> Works fine for me,  thanks Theo !

On IRC discussion with Theo, he recalled that there is one thing left to do for the(his) patch:
On single-click-activation (behvior tab in the settings), in detailed view, when multiple files are selected:
click on one file --> all files will be opened.

In icon-view single-click-activation works fine.
Comment 55 Reuben Green editbugs 2020-04-06 23:44:39 CEST
(In reply to alexxcons from comment #54)

Hum, this bug does not want to go quietly... I'll try to take a look at this soon

Thanks!
Comment 56 Reuben Green editbugs 2020-04-12 16:45:40 CEST
Created attachment 9708 
patch to fix regression

So here is a patch incorporating Theo's diff and a fix for the single-click bug in details mode. To fix the single-click mode, I have basically just copied what Theo did in his diff, by adding a flag variable to show whether the most recent activation was via a mouse click or a key press.

What I've done feels like a bit of a hack, but I think the real solution to this bug may be some changes to exo to avoid all these work-arounds in Thunar. Another one for the to-do list!

I have only given this a very quick test so beware, but I will use it for a few days to check that this fix has not broken anything else...
Comment 57 alexxcons editbugs 2020-04-12 22:08:34 CEST
(In reply to Reuben Green from comment #56)
> Created attachment 9708 
> patch to fix regression
> 
Thanks alot Reuben, works fine here!  Now we have consintence across the views .. as well on code level ;)

Before pushing it, few things are pending:
- The TODO in icon-view.c should not be part of this commit. A separate bug with a separate patch, removing the whole method, would be nice.
- As you already mentioned, a bug for exo should be opened.  It would be great if you could take care, since you know the details.
- Ping Theo: ok for you to commit it like that, with the "TODO" removed ? (since you will be the author)
Comment 58 Reuben Green editbugs 2020-04-14 01:17:13 CEST
Created attachment 9724 
patch to fix regression

So here is a fix for this on master. This patch should be applied after the patch in Bug #16692 (see below). Thanks for your help getting this done, Theo!

(In reply to alexxcons from comment #57)
> - The TODO in icon-view.c should not be part of this commit. A separate bug
> with a separate patch, removing the whole method, would be nice.

I have tested and the TODO is correct, the method is no longer needed in master. I've made a patch to remove it, see Bug #16692.

> - As you already mentioned, a bug for exo should be opened.  It would be
> great if you could take care, since you know the details.

I'll open a bug in exo for this, but it might be a little while until I do, as I want to have a closer look at exo (which has clearly had some changes since I last looked at it) and try to understand what the problem is exactly and how to solve it.
Comment 59 Git Bot editbugs 2020-04-14 11:17:57 CEST
Theo Linkspfeifer referenced this bugreport in commit 99ba79edf3ee3f05360ea2604efdb5f0af47848d

Allow drag-and-drop of multiple files in icon view (Bug #2487)

https://git.xfce.org/xfce/thunar/commit?id=99ba79edf3ee3f05360ea2604efdb5f0af47848d
Comment 60 alexxcons editbugs 2020-04-14 11:21:13 CEST
Pushed the fix to master. Thanks alot Reuben and Theo!

> I'll open a bug in exo for this, but it might be a little while until I do, as I want to have a closer look at exo (which has clearly
> had some changes since I last looked at it) and try to understand what the problem is exactly and how to solve it.
That would be much appreciated, thanks !
Note that you dont need to come up with a solution .. for the first it will be sufficient to just describe the problem.
Comment 61 Git Bot editbugs 2020-04-14 21:49:24 CEST
Theo Linkspfeifer referenced this bugreport in commit 99ba79edf3ee3f05360ea2604efdb5f0af47848d

Allow drag-and-drop of multiple files in icon view (Bug #2487)

https://gitlab.xfce.org/xfce/thunar/commit/99ba79edf3ee3f05360ea2604efdb5f0af47848d

Bug #2487

Reported by:
Mathias Brodala
Reported on: 2006-11-01
Last modified on: 2020-04-14
Duplicates (5):
  • 2568 "enter" key behaves funny
  • 5943 Activating multiple selected items
  • 7841 Open all selected files when pressing Enter.
  • 13767 Selecting images in Thunar and pressing enter opens unselected images as well in Ristretto
  • 16384 Select files via rubberband and open them via shortcut will open last file in folder instead

People

Assignee:
Reuben Green
CC List:
16 users

Version

Attachments

Possible fix (1.83 KB, patch)
2006-11-13 11:47 CET , Benedikt Meurer
no flags
patch to allow multiple file selections to be opened via the keyboard (4.76 KB, patch)
2020-02-14 23:31 CET , Reuben Green
no flags
patch to allow multiple file selections to be opened via the keyboard (8.15 KB, patch)
2020-02-18 15:20 CET , Reuben Green
no flags
patch to fix regression (1.40 KB, patch)
2020-03-27 17:05 CET , Reuben Green
no flags
quick diff (4.07 KB, patch)
2020-03-29 13:20 CEST , Theo Linkspfeifer
no flags
patch to fix regression (3.37 KB, patch)
2020-03-29 13:45 CEST , Reuben Green
no flags
patch to fix regression (6.61 KB, patch)
2020-04-12 16:45 CEST , Reuben Green
no flags
patch to fix regression (4.74 KB, patch)
2020-04-14 01:17 CEST , Reuben Green
no flags

Additional information