#356 closed defect (fixed)
ensight with win32 client has drop down focus problems
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 0.12 |
Component: | client | Version: | |
Keywords: | win32 | Cc: |
Description (last modified by )
Running EnSight Free (proprietary with a "free" version)
- click on File -> Open
- try to interact with "File Type" (also affects the drop down menu found in "Format")
This affects all versions, including trunk.
This only affects the win32 client (not tested OSX) but not the Linux clients.
Change History (13)
comment:1 Changed 8 years ago by
Description: | modified (diff) |
---|---|
Status: | new → assigned |
comment:3 Changed 8 years ago by
Found another related bug, which affects Linux clients too this time: the dialog window is modal ('window-type': ('DIALOG', 'NORMAL')
) and so we block input to all the other windows until it is dismissed - including our own windows like "session-info".
The reason why the drop down remains above all other windows on win32 is because there are no "group leaders" on win32, so when we set a window to be "above others" we cannot specify which other windows it is above of and it ends up being above all of them..
But on Linux, the "group-leader" stuff should work and we should still be able to interact with the other windows.
Maybe we can drop 'DIALOG
' and see what happens?
Next strange thing: when processing clicks from a Linux client, I see for each click:
will process ui packet button-action will process ui packet button-action
That's 2 events: one for press and one for release.
But with a win32 client only one:
will process ui packet button-action
Adding a bit of debug in mouse events, I see:
_button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=194.00, y=70.00, button=1>, False) \ pointer=(281, 170), modifiers=['mod2'], buttons=[1] _button_action(1, <gtk.gdk.Event at 00B4F518: GDK_BUTTON_RELEASE x=194.00, y=58.00, button=1>, False) \ pointer=(281, 158), modifiers=['mod2'], buttons=[1] _button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=196.00, y=47.00, button=1>, False) \ pointer=(283, 147), modifiers=['mod2'], buttons=[1] _button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=196.00, y=78.00, button=1>, False) \ pointer=(283, 178), modifiers=['mod2'], buttons=[1] _button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=193.00, y=116.00, button=1>, False) \ pointer=(280, 216), modifiers=['mod2'], buttons=[1] _button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=192.00, y=140.00, button=1>, False) \ pointer=(279, 240), modifiers=['mod2'], buttons=[1] _button_action(1, <gtk.gdk.Event at 00B4F5C0: GDK_BUTTON_RELEASE x=192.00, y=153.00, button=1>, False) \ pointer=(279, 253), modifiers=['mod2'], buttons=[1]
So on win32 we get a button release, but never the button press... which gets the server all confused: it rightfully ignores the button release since we never told it where/when we did the button press.
comment:4 Changed 8 years ago by
comment:5 Changed 8 years ago by
The group-leader stuff is non-trivial, we now have improvements:
- r3703 makes the server expose the client application's "group-leader" info (if it exists)
- r3705 uses this new "group-leader" info (and fallsback to using the pid as before)
- r3704 fixes when we set the group leader so it will be set correctly before the window is mapped (gtk2 only)
But we still have window focus problems... we can focus away from the modal window, but somehow it regains focus on the next event.
comment:6 Changed 8 years ago by
I am afraid that the fix for modal windows stealing the input focus is very hard indeed, this mozilla bug from 2001 shows that this is a gtk limitation: it blocks input events to all the windows when a modal window is shown.
Their fix keeps track of which windows can receive events and only steals those events for the modal window when the parents of a modal window receive them, letting other windows get their events as expected.
Our options:
- do something similar
- re-use the gdk event loop code to deliver events ourselves
- if another, non-modal window receives the input focus.. only dirty hacks come to mind
Also somewhat related to: #336, #214
FWIW: Qt does things differently: WindowModality-enum supports NonModal
, WindowModal
(which is what we want) and ApplicationModal
(which is what gtk does)
comment:7 Changed 8 years ago by
r3708 removes "modal" window support from gtk2
We'll need to check that this doesn't cause any regressions with modal windows and focus..
comment:8 Changed 8 years ago by
The popup menu sticking on top of windows when one switches away from it has been dealt with in #336: we don't do input grabs, we just manually manage OR windows losing focus server-side.
comment:10 Changed 8 years ago by
Milestone: | 0.10 → 0.11 |
---|---|
Owner: | changed from Antoine Martin to Antoine Martin |
Status: | assigned → new |
Re-scheduling, focus and grabs will be a priority for 0.11
comment:11 Changed 7 years ago by
Milestone: | 0.11 → 0.12 |
---|---|
Status: | new → assigned |
re-scheduling (again)
comment:12 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Looks like #139, which is fixed. I don't want/care/have ensight, so closing.
comment:13 Changed 5 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/356
Here's the information on the dialog window that shows up when one clicks on "File -> Open" (captured client-side):
And this is the "window" that contains the drop down menu:
When we click on the drop down menu with the Linux client, we see (server side):