Community
Participate
Working Groups
In SWT/gtk, any window that has a parent and is decorated (has any of the style hints SWT.TITLE, SWT.MIN, SWT.MAX, SWT.CLOSE, SWT.BORDER etc. set) gets by default a dialog window type hint. This happens in the Shell.java class, by calling the OS function gtk_window_set_type_hint(window, GDK_WINDOW_TYPE_HINT_DIALOG). As a result of this call, in CentOS running Metacity 2.28.0, the window’s titlebar can’t contain any other button except the close one (no buttons for minimize or maximize can be added). Is there a specific reason why the type of any window that has a parent has to be a dialog?
The problem affects and was tested on CentOS running Metacity 2.28.0 and gtk2-2.24.23-6. For this system configuration, shells can have the following decorations on the titlebar: main window: _■X, _X, X child window: X For comparison, in Windows, the available decorations are: main window: _■X, ■X, _X, X child window: _■X, ■X, _X, X In GTK, the issue is twofold: - The function gtk_window_set_type_hint(window, GDK_WINDOW_TYPE_HINT_DIALOG) doesn’t allow anything on the titlebar except for the close button. In SWT/gtk the GDK_WINDOW_TYPE_HINT_DIALOG type hint is set for all the windows that have a shell as a parent. - The gdk_window_set_decorations (window, decorations) call produces on the titlebar only the button combinations listed above. However, any combination of the SWT.MIN, SWT.MAX and SWT.CLOSE style bits is accepted by the Shell objects. SWT currently uses only the gdk_window_set_decorations function for styling the titlebar. However, GTK has another function that affects the titlebar buttons: gdk_window_set_functions. By calling it, all button combinations are available on the titlebar: _■X, X, ■, _, _■, ■X, _X, but this function isn’t implemented by the OS class of SWT/gtk. We have a fix for these issues that removes the gtk_window_set_type_hint(window, GDK_WINDOW_TYPE_HINT_DIALOG) call for child shells and adds the gdk_window_set_functions(window, functions) function to the OS class of SWT and calls it when the shell needs to be styled, thus fixing the problem for Metacity. Would you be interested in a contribution?
We would we happy to have contributions from the community. Please follow the guide lines listed here for SWT http://www.eclipse.org/swt/index.php. Please upload you patch to gerrit for review
Hello, please find the patch here: https://git.eclipse.org/r/#/c/39372/
Hi, I looked at the code. Here is the problem I noticed Try to run Snippet50 from the snippets package. Here we create a new shell with Dialog as style. This should not get the minimize and Maximize buttons. but with this change we are getting these. This needs be corrected. Thanks Sravan
Thanks, We will submit a fixed version. Cheers, Eugen
Hi, I uploaded a new patch set to Gerrit. It should fix the issue. Cheers, Alexandra
Gerrit change https://git.eclipse.org/r/39372 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=b73210b3ae347e174d94d1d65890dbcff0242ce4
Patch pushed to master.
(In reply to Alexandra Buzila from comment #0) > Is there a specific reason why the type of any window that has a parent has > to be a dialog? This seems to be required for full screen mode. It is broken now. Dialogs opened while in full screen mode no longer show - they are opened, but hidden behind the full screen window. I've proposed a possible solution/workaround in https://bugs.eclipse.org/bugs/show_bug.cgi?id=487786
Removing the dialog hint has caused the window manager to position new shells differently. When the hint was set then dialogs are centered over their parent. After this change the window manager is attempting to position the dialog independent from its parent(in my configuration it seems to try to find free space or if the parent is maximized it just goes to the upper left corner). We can easily work around this by manually calculating the center of the parent and positioning the dialog but the gtk documentation mentions this use case specifically and indicates it is better to set the hint(See Note 3 at https://developer.gnome.org/gtk2/stable/GtkWindow.html#gtk-window-get-size). Would it be better to set the hint only if it does not conflict with the other style bits? At the very least the Dialog class should have some way of setting the hint for its shell since classes extending Dialog should be treated as dialogs by the window manager.
