[Tracker] Windows are not raised to front when clicking on files directly

[x-ist]

1. Open two Tracker windows.
2. Place them such that one is covered by another partially.
3. Click on a file within the covered window.
4. The file is selected, but the window is not raised as one would expect.
5. However clicking on an empty area instead of a file raises the window.

[leavengood]

I'm not positive, but I suspect this behavior is on purpose to allow one to copy a file from another window without your current window losing focus.

Though it might work better if it brought the other window forward if the mouse comes up. Then if you wanted to copy a file from another window you could click it and drag it over and the active window would not change, but if you clicked it and released the mouse, then the other window would come to the front.

[x-ist]

Replying to leavengood:

I'm not positive, but I suspect this behavior is on purpose to allow one to copy a file from another window without your current window losing focus.

That could really be a use case, however it works for one file only, if I understood correctly. On the other hand there could be consistent behaviour which I would prefer instead, since one switches focus between windows much more often, compared to moving one file across them.

Though it might work better if it brought the other window forward if the mouse comes up. Then if you wanted to copy a file from another window you could click it and drag it over and the active window would not change, but if you clicked it and released the mouse, then the other window would come to the front.

That would make more sense it think.

[humdinger]

I'd prefer to keep the behaviour as is. If you want to bring a window to the front, just click anywhere besides a file icon/name. There's usually enough whitespace around. Or click the border/tab or hold CTRL+ALT and click anywhere.
You can mark more than one file while holding ALT or SHIFT, so raising the window on mouse up wouldn't be nice. Having windows pop to the front when just drag&dropping a file is one of the major grievances I suffer in other OSs...

[axeld]

I find Ryan's suggestion would make a good compromise. The current behavior is like this to enable drag&drop to work properly -- the changes Ryan suggests would not break this, but also allow the expected action of bringing the window to front.

I'm afraid there is no system-wide consistent way to implement this, so maybe that's the best we can have.

BTW there are tons of duplicates of this bug. I guess after the proposed changes, we'll still get bug reports telling us that Tracker windows will only come to front on mouse up. Oh well.

[humdinger]

OK. Would it be possible the window were not raised if ALT or SHIFT were held on mouse up? Then the multiple file selection before drag&drop would still work.

[axeld]

That sounds good to me. Of course, the window should also only rise in the appropriate mouse modes (ie. not in FFM).

[axeld]

If selecting multiple files gets too annoying this way, we could still revert it or have it as an option only (possibly a text file only option, though).

[bitigchi]

I cannot reproduce this. I tried both "Accept first click" on and off (with click to focus and raise). Can someone else try it as well?

[jscipione]

This bug was fixed in hrev53883

[jscipione]

Fixed in hrev53883

[nielx]

Assign fix to milestone:R1/beta3, as it looks like this fix will be part of that release.

As we started with the previous beta, we would like to use the Milestone field for fixed tickets to log from which release the improvement will be out. Therefore it is very much appreciated to assign the milestone when closing a ticket as fixed.