Thunar Lasso select in Detailed View not always working

The behaviour of lasso-selecting multiple files seems buggy to me.

If I kill all instances of thunar then start a new instance, lasso-select works fine. I left click on any file or folder in the columns to the right of the Name column and can drag the selection up or down as expected.

Then I go to drag and drop a single file/folder so I depress the left mouse button over a file or folder in the Name column and can drag it with the mouse. Again, that is normal behaviour as expected.

The problem is that I am then unable to use lasso-select again! It is like the mouse select option stays on single file/folder drag and drop from that point onwards, even though I am trying to lasso select from columns other than the Name column.

I'm using Thunar 1.8.14 on Xubuntu 20.04

Indeed. I can reproduce this bug with git master too.

0001-Fix-unavailable-rubber-banding-in-detailed-view-Fixes-326.patch

closed via commit 518f4e3c

mentioned in commit 29149fd9

Thanks for the patch Theo!

Works fine and seems to have no side effects, so applied it to master and 4.14 branch.

One thing I noticed: The same bug as well exists when you start the rubber-banding below the list of files. That one seems not to be fixed by your patch.

Since the bug title still matches, I'll keep the bug open.

reopened

The same bug as well exists when you start the rubber-banding below the list of files.

In that case the added code line has to be moved up a level (before the path != NULL check).

In that case the added code line has to be moved up a level (before the path != NULL check).

Thanks, that seems to fix it .. very strange that rubber-banding has to be enabled over and over again on any-buttom-press. Specially I did not find any call which disables it. The property "rubber-banding" is not used anywhere.

So ok, I have no idea why it is needed, but it fixes the bug :) .. Theo, since you found the fix, ok if I commit the re-location of the call in your name ?

Specially I did not find any call which disables it.

This is done in exo-tree-view. I have not spent much time reading and understanding all of it because just (re)enabling rubber banding in Thunar's code instantly fixed the problem.

Theo, since you found the fix, ok if I commit the re-location of the call in your name ?

Feel free to move the line.

Hmm, maybe I was a bit fast with pushing the first fix.

Meanwhile I think this one should rather be fixed in exo to have some symmetry for enabling/disabling rubber-banding in the code .. to disable it in one package and to enable it in another feels kinda wrong :)

Looks like in exo the bool button_release_enables_rubber_banding for some strange reason does not work .. I did not further investigate on that variable, but just dropped it, since your solution as well seems to work fine in exo.

If ok for you, I would push the attached patch to both exo branches and revert the commits on thunar master and 4.14.

0001-Fix-unavailable-rubber-banding-in-detailed-view-Fixe.patch

I think rubber banding in exo-tree-view should still be optional.

https://gitlab.xfce.org/xfce/exo/-/blob/master/exo/exo-tree-view.c#L333

Hmm, think it never was.

Till now in exo I guess the idea was to disable rubber-banding for DnD and enable rubber-banding after DnD got finished (which seems not to work that well)

According to the gtk doc rubber-banding is disabled by default .... I wonder if that is correct, because it works pretty well without setting it.

So with my patch we explicitly would have it activated on the first click, not only after doing a DnD. Seems to work fine, or ? My assumption would be, that we can just drop that check in line 333.

I wonder if that is correct, because it works pretty well without setting it.

https://gitlab.xfce.org/xfce/thunar/-/blob/master/thunar/thunar-details-view.c#L235

Meh, sorry, you are right, I did not see that one.

Though still think we should fix that in exo (or maybe just remove the defect part there and only handle things in thunar) ... I'll look into it again when I have time.

Apply the easy fix for now and maybe look at it again later?

mentioned in commit d501ae53

mentioned in commit 9b4a8b9c

You are right, pushed it to master and 4.14.

I'll keep the bug open for later, and add it to my personal, ever growing list :)

added 5. Drag-and-Drop 5. List View (Detailed View) labels

I say that we close the report. Chances are low that we will mess around with this code part anytime soon (or at all).

Fine for me, if I come back to it one day, I can reopen :)

closed