Community
Participate
Working Groups
Please provide API to create a KDE utility window. From bug 52669 comment 27, "Modern window managers have a more expressive notion of window types, and so arguably we should be setting detached views as "utility windows", which would have the nice side-effect of making KDE not enforce its dialog policy on them. However, this would require new API from SWT." It sounds as though a utility window may be the KDE version of a windows tool window (SWT.TOOL). If so, it may be possible to support this without any additional flags.
Sounds good. FH to investigate exactly what is meant by "KDE utility window", determine how this might map to SWT API and discuss with SN.
It's not specific to KDE, it's the window type property from the wm-spec. See gtk_window_set_type_hint(). SWT.TOOL probably maps to GDK_WINDOW_TYPE_HINT_TOOLBAR, which is not really what we intended for detached views. We were looking to set those as GDK_WINDOW_TYPE_HINT_UTILITY.
I can set GDK_WINDOW_TYPE_HINT_UTILITY when style SWT.TOOL is requested for Shell. You can try adding this to Shell#createHandle: if ((style & SWT.TOOL) != 0) { OS.gtk_window_set_type_hint (shellHandle, 5 /*GDK_WINDOW_TYPE_HINT_UTILITY*/); System.out.println("GDK_WINDOW_TYPE_HINT_UTILITY"); } Setting that on GTK will set _NET_WM_WINDOW_TYPE_UTILITY on the XWindow during the realize of the GtkWindow. The think is: I tested this on metacity, fluxbox, sawfish, and kwin and none of these window manager do anything (visually) for this hint. Run the ControlExample on Win32, in the Shell tab, check what SWT.TOOL is suppose to do. GDK_WINDOW_TYPE_HINT_UTILITY doesn't do anything like that.
I tested against metacity 2.8.1 and KWin from KDE 3.3.0. GDK_WINDOW_TYPE_HINT_UTILITY - On both kwin and metacity, the window title bar is shorter than normal and used a smaller font. - On both kwin and metacity, there was no minimize button, and the window was always on top of its parent. - On kwin, the utility window appears in your task list, but only if the main window has focus. - On kwin, the window does not appear in the alt-tab list. - On metacity, the window appears in the alt-tab list. - On kwin, the utility window disappears if focus is given to another top-level window. - On metacity, it had no maximize button, but it does on kwin. GDK_WINDOW_TYPE_HINT_TOOLBAR - On kwin, the window appears with a title bar, but no close, minimize, or maximize buttons. - On kwin, the window does not appear at all in the task list. - On metacity, the window appears with no trim at all. - On metacity, the window does appear in the alt-tab list. For comparison, dialogs under kwin: - Have normal sized trim - Stay visible when other top-levels have focus. These hints clearly do something. Now that I have done some testing, I think that the UTILITY hint maps well to what we expect from SWT.TOOL. While the TOOLBAR hint sounds more reasonable, because it gives no trim at all on metacity and does not have a close button on kwin, I do not think we should use it. This hint was designed for the detachable toolbars from GNOME and KDE which provide their own drag handles.
To clarify what I meant by "another top-level window", if I have a utility window open in Eclipse, and switch to give my web browser focus, the utility window will be unmapped.
closing as wont fix. SWT.TOOL is our answer for this problem.
