[Feature request/Bug] Floating bar & islands should respect Fitt's law

[saligari]

Under vanilla GNOME you don't need to hit exactly on the top-bar's widget to select/click on them. When the cursor is all the way on top, you are hovering over the widget & can click to expand.

In KDE the floating panels respect Fitt's law in the same way; go all the way to the edge of the screen, the widgets are still selected.

This does not happen with this extension (at least on my pc) but I suspect this is not a bug, but the way it is now supposed to work. It is a shame as it requires more fine control to select the widgets as they exist in (x,y) instead of (x,0). There is never going to be something above the widgets to select so there is no reason why they should not be select-able when the cursor is in the (proper) x,0 spot.

Thanks! The extension is really great!

[neuromorph]

Hello,

Agreed! This is a pet peeve for me as well. However, it is not clear how the (x, 0) can be efficiently implemented.

Under vanilla GNOME you don't need to hit exactly on the top-bar's widget to select/click on them. When the cursor is all the way on top, you are hovering over the widget & can click to expand.

Gnome has the Panel touching the top edge of the screen. The buttons are inside the Panel and are also spanning full height and so touch the top edge. They've added a few pixels wide transparent border to buttons to create illusion of narrower buttons inside the panel. So, when the pointer is at the top edge, it is also on the button and it works that way.
When we move the Panel away from the edge, like in this extension, the buttons can no longer reach the top edge and so they don't get the pointer event signals.

In KDE the floating panels respect Fitt's law in the same way; go all the way to the edge of the screen, the widgets are still selected.

Good to know. I am not aware of how KDE is doing it but then again their Panel implementation is likely different from that of Gnome.

The idea then would be to listen to pointer events on the panel/box and manually handle the event to open a menu if pointer was above it. Tracking pointer through js may not be efficient so maybe only clicks. I will try something on this line. Feel free to share if you have any specific ideas.

This is also a reason I personally don't use 'Vertical padding' option in the extension and keep zero margin in WMax bar so that at least when a window is maximized (which is most of the time) I can click on the top edge to open a menu :)

Thanks! The extension is really great!

Thank you! And thanks for raising this issue, let's see if we can fix it or at least make it better.

[saligari]

This is also a reason I personally don't use 'Vertical padding' option in the extension and keep zero margin in WMax bar so that at least when a window is maximized (which is most of the time) I can click on the top edge to open a menu :)

I found that if Vertical padding is 1.4 then (on my screen) I can click if on the top edge.

Unfortunately, the extension crashes my gnome session for some reason so I disabled it.

[neuromorph]

I found that if Vertical padding is 1.4 then (on my screen) I can click if on the top edge.

Ah cool. I think it is the combination of bartype/margin/border/padding that can result in the button being able to reach the top edge and make it work. I have thought about it and have some idea on how it could work in all cases but it will be rather involved. I will work on it in a separate branch as time permits.

Unfortunately, the extension crashes my gnome session for some reason so I disabled it.

That's unfortunate indeed. If you were using Candybar with colorful buttons then it is related to this issue. The main issue is upstream in Gnome/mutter but I am not able to figure out why it is triggered with Candybar but not otherwise. Also, I am not facing it lately (could be a patch in Ubuntu). If you like, you can give the version in main branch a try, it has a fix-attempt.

[saligari]

I tried the version in main branch but still it crashes :(

[neuromorph]

I tried the version in main branch but still it crashes :(

That's disappointing :(

Can you please let me know:

• is the case same as the above linked issue, as in it only happens with Candybar On but not if Candybar is Off?
• can you get me the crash log if possible. This will help to verify if the stack trace is same as the upstream issue and also in case there is any pointer to what exactly is triggering the crash.

Thank you!

[saligari]

I'm 99% sure it happens regardless of the candybar, how do I get the crash log?

[neuromorph]

Hello,

For the main issue here about Fitts Law:
I have added commits to the main branch with this feature. This allows to access the button from proximity within the PanelBox - including the screen edge. As mentioned earlier, it was a bit convoluted to implement given the hierarchy of panel widgets and their dynamic nature. Dynamic, as in, any app/extension adding removing buttons to the panel at any time. There may still be some exceptions where an extension adds a panel button in some non-standard way. Nevertheless, it should work in general and also I have added a toggle under 'Top Bar Properties' called 'Enable Buttons Proximity' to enable or disable this feature. Any feedback is highly welcome.

I'm 99% sure it happens regardless of the candybar,

About the crash, there are two open issues: issue #35 and issue #63 . If your issue is similar to any of them, we can track it there. Frankly, they are the same issue with slight variation on the state it is triggered in (i.e. trilands vs. candybar). Both of these happen when locking screen or suspend. So when trying to resume, Gnome shell would have restarted.

how do I get the crash log?

Immediately after the crash, i.e. after Gnome has restarted,

• we can use journalctl to grab last boot log - journalctl -b0 or journalctl -b1.
• or coredumpctl list to list the crashes and then coredumpctl info on relevant one.
• the Logs app can also show some details with a GUI
• in some DEs, in this session just after crash, you will be prompted to send report to the developers. In that dialog, there is option to check details and that will show stacktrace.

In the crash log, I search for 'neuromorph', 'openbar', 'stylesheet' or the typical candidate in this issue 'st_theme_node_lookup_shadow' to find relevant part.

Thank you!

[neuromorph]

The new version v41 with support for Gnome 47 and Fitts law is now live!

Feel free to log a new bug for other issues.