Bugzilla – Full Text Bug Listing
| Summary: | SWT ON_TOP dialogs using gtk can stop receiving all events on mutter | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nate Jensen <ndjensen> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Benjamin.P.Steffensmeier, ipun, jan.public, lufimtse |
| Version: | 4.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=515773 | ||
| Whiteboard: | |||
|
Description
Nate Jensen
I should have been more clear. We tested on Linux environments with the window manager as Mutter, Metacity, Muffin, and Openbox. Out of those four, the issue only occurred on Mutter. Mutter is the window manager for Gnome 3 and Gnome Classic. Following the link to the Gnome bug, there are attachments of two Java files to recreate the issue with SWT. There is also a C file attached there to recreate the issue with pure GTK. Test steps are in the comments there. I have done some research on this and there seems to be a disconnect between what you can do with SWT.ON_TOP, what gtk recommends, and what the window manager is required to do. SWT.ON_TOP is not well documented so it isn't clear what is required. Obviously it should cause the shell to be on top of other windows but it also seems to force SWT.NO_TRIM causing confusion such as https://bugs.eclipse.org/bugs/show_bug.cgi?id=410810. Currently an ON_TOP Shell is converted to a GTK_WINDOW_POPUP type of window which is translated to the window manager as an OR (override redirect) window. On the mutter bug that Nathan has linked Rui (a mutter developer) points out that OR is not guaranteed to be on top and recommends SWT should not be using it. In the GTK documentation it mentions that GTK_WINDOW_POPUP should be used for things like tooltips and menus but not for regular dialogs, however SWT does not document that. I think it is common for applications to use ON_TOP for dialogs that are not tooltips or menus. SWT should either document similar limitations or it should change which GTK API it is using. Based off the GTK documentation it looks like SWT.ON_TOP would be more consistent if was a toplevel window (not a popup) with gtk_window_set_keep_above and gtk_window_stick, and possibly gtk_window_set_undecorated. Such a change would also make it easier to support extended cases like ON_TOP with DIALOG_TRIM because the keep_above and undecorated settings could be controlled independently, which is not possible with GTK_WINDOW_POPUP. Is there anyone who can explain why SWT is using GTK_WINDOW_POPUP instead of gtk_window_set_keep_above? (In reply to Ben Steffensmeier from comment #2) > Is there anyone who can explain why SWT is using GTK_WINDOW_POPUP instead of > gtk_window_set_keep_above? Ian has been working a related issue involving the POPUP business. See "see also". @Ian, feel free to comment. Popups have the feature that they're put on top of all other widgets. I think they were used to get that 'always on top' functionality. However, POPUPS typically don't gain focus. To get focus in such widgets, an x11 hack was employed to redirect focus 1*. (On wayland this mechanism doesn't exist and is causing Bug 515773.). I think the redirect hack is probably causing the issue in this bug. I agree, it's not the most suitable candidate for a child shell. An alternative implementation would be better imho. However, do note, on Wayland a child shell cannot be positioned relative to a parent. I.e set x/y don't work. So care must be taken not to break x/y coordinate of child shells of SWT.ON_TOP such that common eclipse hovers don't break. GTK_Popover seems like candiate, but it has that little visual /\ triangle poping up from where it spawned. If it's possible to not render it, it might be a suitable alternative for child shell with SWT_ON_TOP. If someone does implement, things to test: - Javadoc hover should work and should show at the right position. - Launchbar popup should work (see Bug 515773) and launch at the right position. [1] Redirect hack, see Shell.java:568 > * Feature in GTK. When the shell is an override redirect > * window, gdk_window_focus() does not give focus to the > * window. The fix is to use XSetInputFocus() to force > * the focus." > ... As of this guy, I got things to work well in mutter: https://git.eclipse.org/r/#/c/122135/ I.e, keyboard and mouse events are handled properly. I setup mutter as per: https://bugs.eclipse.org/bugs/show_bug.cgi?id=533710#c2 I.e, mutter with Wayland backend. If there is still an issue with latest commit (above), then please re-open the bug and post steps to reproduce. |