After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 132501 - Make utility window translate to tool window in win32
Make utility window translate to tool window in win32
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.14.x
Other Windows
: Normal enhancement
: Small fix
Assigned To: gtk-win32 maintainers
gtk-bugs
: 554860 555527 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-01-25 20:45 UTC by codemstr
Modified: 2008-11-23 15:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description codemstr 2004-01-25 20:45:48 UTC
Looking up what the "utility window" option is, it seems as though this 
is roughly equivilent to a "tool window" in MS Windows. That way the tool 
windows can stay on top of your other windows, e.g. an image window. This 
seems to be what a utility window is from what I've read.

Note: This feature is actually for Gimp, but talking to people, it seems 
as though the "utility window" feature of Gimp is actually handled by 
GTK+ so I hope I'm posting this in the right place.
Comment 1 Tor Lillqvist 2004-01-25 22:34:07 UTC
Er, which GIMP windows are "utility windows"?
Comment 2 codemstr 2004-01-25 22:43:01 UTC
I guess one of the developers will have to answer that, all I know 
is I was told it would solve my problem of things like the layers 
window or the brushes window refusing to stay on top. And since tool 
windows do the same thing on Win32, it seemed logical.
Comment 3 Tor Lillqvist 2008-10-04 20:30:30 UTC
*** Bug 554860 has been marked as a duplicate of this bug. ***
Comment 4 Tor Lillqvist 2008-10-05 00:03:16 UTC
This is now mostly fixed in gtk-2-14 and trunk:

2008-10-04  Tor Lillqvist  <tml@novell.com>

	Bug 132501 - Make utility window translate to tool window in win32

	Implement the utility window type hint. Such windows are kept on
	top of other windows. Makes GIMP's toolbox and dock windows behave
	more like in GNOME under metacity. Apply the same logic also to
	windows marked with the dialog window type hint, and windows that
	are transient for some other window. I'll call such windows
	"transient-type" below.

	* gdk/win32/gdkevents-win32.c (doesnt_want_key): Drop unused
	variables.

	(ensure_stacking_on_unminimize)
	(ensure_stacking_on_window_pos_changing)
	(ensure_stacking_on_activate_app): New functions to implement the
	desired stacking order. Make sure that a window that is not
	transient-type stays below any transient-type windows of the
	application. When activating a non-transient-type window make sure
	it rises as high as possible.

	(gdk_event_translate): Call above functions on
	WM_WINDOWPOSCHANGING, WM_ACTIVATEAPP and on WM_SIZE when
	unminimizing. Improve debugging printout.

	* gdk/win32/gdkwindow-win32.c (get_effective_window_decorations):
	Handle utility windows like toolbar windows.

	(gdk_window_new_internal) (update_style_bits): Give utility
	windows the WS_EX_TOOLWINDOW extended style.

	(gdk_window_set_title): If debugging "misc" or "events", make the
	handle of top-level windows show up in their title bars. Very
	useful when looking at debugging output.

	(gdk_window_set_keep_above) (gdk_window_set_keep_below)
	(gdk_window_set_modal_hint) (gdk_window_set_skip_taskbar_hint)
	(gdk_window_set_skip_pager_hint): Add and improve debugging
	printout.

	(gdk_window_set_type_hint): Print hint symbolically in GDK_NOTE().
Comment 5 Tor Lillqvist 2008-10-08 11:33:29 UTC
*** Bug 555527 has been marked as a duplicate of this bug. ***
Comment 6 Peter Clifton 2008-11-23 15:53:02 UTC
Can anyone confirm if this patch has produced unintended side-effects?

I've just rebuilt our app (gEDA/gschem) against 2.14.4, and have found all our dialogs (which IIRC, are transient-for), get wedged behind our main window.