[LinuxCNC/linuxcnc Issue#377] funny halscope window behavior on 2.7/stretch

#1 – andypugh 于 2017-12-11

There is another “funny” I found in Halscope too, but couldn’t figure out a way to reproduce it (but managed to to it twice). If you drag in the trigger/zoom display (not the controls) then Halscope can become entirely unresponsive.

#2 – havardAasen 于 2021-07-10

I was able to reproduce this issue on, Debian buster, with both 2.7 and 2.8, RIP setup. I could only reproduce it with the gnome desktop, with mate, it wasn’t an issue. The issue also exists if halscope is run without LinuxCNC, and it affects almost all of the dialog windows. The ones not affected is the ‘file open/save’ and ‘about’ dialog windows.

I can make a PR if you like, it would target 2.7 and 2.8. It’s one line of code, possible two, for each dialog window.

The proposed fix will “detach” the dialog window from the main window, it will make the dialog window appear in the center of the screen. Reading the code, this was the intention all along, though it hasn’t been that way. This could be a rather large change.

I would like to change this, so the dialog windows opens where the mouse pointer is. This is close to what it is today and we don’t need to move the mouse all over the screen.

This partly affect master as well, only with two windows that I’ve found so far, ‘about’ and ‘Select Sample Rate’ windows.

#3 – andypugh 于 2021-07-12

I wonder if this is worth fixing? If there is no chance of the fix breaking anything else, then it should be done. But it sounds like there might be.
Given that this seems to be a minor issue on a minority desktop (and not, as far as I know, the default one) perhaps it is best to leave it?

Is the problem still there in master-gtk3? (I don’t know if Halscope is even using GTK)

#4 – rene-dev 于 2021-07-12

in Master halscope was updated from gtk1 to gtk3 recently. No further changes in master-gtk3 branch. If the issue is in master and 2.8 it’s not directly gtk related.

#5 – havardAasen 于 2021-07-12

I would say it’s up to the RM to decide if it’s worth fixing or not, but what I don’t like is that the UI isn’t consistent between desktop environments. Of course, you need to change the environment to notice the difference.

As for breaking. I would believe that in the worst case, the dialog window, opens in a different place on the screen, though I hope to be able to prevent that.

In Debian 10 and 11, gnome is installed as default, not sure how it was before. https://wiki.debian.org/DesktopEnvironment#InstallationofaDesktopEnvironment
That don’t mean LinuxCNC has many users, using the gnome environment.

This is the gtk function that makes dialog windows behave differently:
gtkwindowsettransientfor()
and the gtk documentation https://developer.gnome.org/gtk2/stable/GtkWindow.html#gtk-window-set-transient-for

I’m wondering if it’s up to the window manager to decide how it interprets this function.