Annyoing Desktop file selection behaviour since hrev53660

[humdinger]

This is post-hrev53660

Since hrev53660 selecting files on the Desktop (and more) is off...

• Open a Terminal
• Click on an icon on the Desktop

-> Terminal still has focus, you cannot do a GetInfo with ALT+I for example, though the icon is selected.

You have to click onto the Desktop first, then click the icon.

[X512]

Tracker window focus logic seems to be broken since OpenTracker release. Haiku used different B_WILL_ACCEPT_FIRST_CLICK behavior than BeOS for long time. I try to compare focus logic with OpenTracker later.

[pulkomandy]

We do some changes on purpose. Tracker windows with B_WILL_ACCEPT_FIRST_CLICK are one of these (although as a focuf sollows mouse user, I don't really care).

In any case I think some deviations from BeOS could be intentional.

[humdinger]

Even if the post-hrev53660 behaviour were 100% like BeOS used to be, I think it's a major step back from how Haiku behaved for over a decade. Consider that Haiku has now been used considerably longer than BeOS. IMO it's more important to keep behaviour that people became used to in that time, than totally replicating how BeOS used to work for a few years 20 years ago... :)

[X512]

Without BeOS B_WILL_ACCEPT_FIRST_CLICK behavior, it is not possible to avoid activating window by mouse click, that is required in some cases.

[X512]

I investigated code and found that Haiku Tracker changed mouse tracking code from blocking loop to event based handling. Focus logic was probably broken there.

[humdinger]

I dunno. I installed hrev53659 which does not show what's described. What hrev changed Tracker's mouse tracking?

[X512]

It was probably changed long time ago. Change was not noticeable with wrong B_WILL_ACCEPT_FIRST_CLICK behavior.

[X512]

Proposed fix: ​https://review.haiku-os.org/c/haiku/+/2081.

[humdinger]

Thanks for working on this. Your patch does solves the described issue. However, it introduces the "Tracker windows only pop up on MouseUp". I have to say that I only built Tracker+libtracker.so. Do I have to build more?

[X512]

Replying to humdinger:

Thanks for working on this. Your patch does solves the described issue. However, it introduces the "Tracker windows only pop up on MouseUp".

This is desired behavior, BeOS does the same. Also Tracker activated on mouse down when clicked on background. Some people likes this behavior. Related discussion: ​https://review.haiku-os.org/c/haiku/+/2000.

[humdinger]

Also Tracker activated on mouse down when clicked on background.

It doesn't for me. Clicking in the Tracker window background also only pops it up on MouseUp.

Some people likes this behavior. Related discussion: ​​https://review.haiku-os.org/c/haiku/+/2000.

I know, I'm not one of them... :)

TBH, personally I never noticed the failing B_WILL_ACCEPT_FIRST_CLICK flag, but now feel the repercussions of its fix, and the less annoying, but still grating, fix of the fix that introduces the MouseUp delay. That said, I do appreciate your work on this and know it's all quite complicated.

[humdinger]

This new behaviour is starting to get more than annoying. I lost a few files already...

I have a query window with mails open. I click on a mail and press DEL, not realizing that quietly the Desktop has focus. Instead of the clicked mail, the last selected file on the Desktop gets deleted. If you don't pay close attention, you don't notice that the selected mail file didn't disappear. Before you know it, it's too late to do a ALT+Z on the Desktop and you may even have emptied the Trash before you notice a file/folder missing on the Desktop.

Between losing files and having to endure the MouseUp delay, I chose the delay...

I fnd it kind of amazing that nobody else notices these issues.

[X512]

I click on a mail and press DEL, not realizing that quietly the Desktop has focus. Instead of the clicked mail, the last selected file on the Desktop gets deleted.

Click is usually performed by fast mouse down and up, so there is usually no issue.

Storing something important in desktop folder is a bad idea.

[pulkomandy]

Storing files on the desktop is a totally normal thing to do, and mouse focus should just work. So we should either fix this, or revert the changes.

[X512]

Replying to pulkomandy:

and mouse focus should just work.

It just work as in BeOS now, there are nothing wrong with it. This behavior was implemented in BeOS Tracker intentionally.

If old behavior is preferred, than focus changing logic in Tracker may be disabled. Maybe focus logic should be configurable.

[X512]

Replying to humdinger:

This new behaviour is starting to get more than annoying. I lost a few files already...

Does ​https://review.haiku-os.org/c/haiku/+/2081 applied?

[X512]

Classic MacOS also behave in similar way.

[pulkomandy]

I don't care how OS from the 1990s worked. It's 2020 and we should do things the way that makes sense. If you click on a window it should get the focus and keep it until you click elsewhere. Why would it be otherwise? And the Desktop is just a normal window like all others.

[humdinger]

Does ​​https://review.haiku-os.org/c/haiku/+/2081 applied?

Not before, but I just did. That patch solves the issue I described in this ticket for the price of the mentioned small delay introduced by reacting to the MouseUp. Compared to the current state, it's only a minor annoyance that I'm sure I can get used to. :)

So, +1 for me for merging that patch.

[waddlesplash]

Merged in hrev53883. Thanks!

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone