GNOME Bugzilla – Bug 148535
add drop shadow to menus, tooltips, etc. under Windows XP
Last modified: 2007-06-10 18:28:42 UTC
On Windows XP, it is normal for tooltips, menus, and other similar windows to have a drop shadow displayed under them. This type of window is what the GDK window type GDK_WINDOW_TEMP covers, so it would seem that all windows of this type should have a drop shadow. The drop shadow is created by setting the CS_DROPSHADOW bit in the class style. Windows 2000 or less does not support drop shadows. I will create a patch that adds this feature.
Created attachment 29918 [details] [review] Patch against gtk+-2.4.1 Note that as well as adding the CS_DROPSHADOW class style, I have changed gtkdnd-win32.c so that it ignores the drop shadow (which is implemented by win32 as a separate window) when searching for drop windows.
Temporary windows have no semantic meaning and may be used for any borderless window that doesn't need to receive focus. You'd have to modify the GTK+ core in some way to provide the necesarry semantic information.
Ah, I see. I assume that the correct way to do this be to add GDK_DECOR_DROPSHADOW to GdkWMDecoration? The appropriate parts of GTK (menus, tooltips, ...) could then set this decoration on their windows when they are realized. The difficulty here is that the drop shadow is a window class style, and cannot be set on individual windows. I could change GDK to create shadowed and non-shadowed versions of all its window classes, but it's not possible to change a window's class after the window has been created. Maybe the solution is for me to work out how to manually create and attach a window of the "SysShadow" class for the existing window.
The natural way in the GTK+ framework would be to use gtk_window_set_role() to set rules like "gtk-menu" on the GdkWindows and then to interpret that in the Windows backend. If you can't change the drop shadow on the fly, we could extend GdkWindowAttr so that the role can be set on creation and make GtkWindow use that. Though it would certainly not be ideal.
From reading the docs, it would seem that gtk_window_set_type_hint would be better. It would maybe require a new GDK_WINDOW_TYPE_HINT_TOOLTIP and maybe even something for dnd-icon windows. The type hint also has the advantage that the documentation already says that it must be set before the window becomes visible.
According to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windowclasses/aboutwindow.asp CS_DROPSHADOW Windows XP: Enables the drop shadow effect on a window. The effect is turned on and off through SPI_SETDROPSHADOW. Typically, this is enabled for small, short-lived windows such as menus to emphasize their Z order relationship to other windows.
As a theme author, I'd like to see this patch committed. It makes GTK+ apps feel less alien on Windows XP. There is a strong relationship between GDK_WINDOW_TEMP's semantics ("override redirect temporary window") and the semantics that SPI_SETDROPSHADOW implies. More importantly, their use cases (primarily used to designate menus, tooltips, auto-complete, and combo box popups) overlap in practice. So, this behavior is correct 9 times out of 10, instead of maybe 1 out of 10. Changing the default behavior to accomodate the primary use cases seems like the right thing to do.
I really think this should be done right (see my previous comment), then with a bad hack that improves 90% of windows and breaks 10% of windows....
BTW - auto-complete and combo box popups don't normally have drop shadows in XP...
Created attachment 61998 [details] [review] Patch, along the lines of what Owen requested This is hopefully more to Owen's liking
Created attachment 62171 [details] [review] previous patch, sans typo
IMO, we should use the window type hints that soeren recently introduced for this.
With the structure of gtk and win32 it's not at all easy to use type hints to add drop shadows. The choice of shadow or not must be made when creating the HWND, as it's a choice between two win32 window classes. The HWND behind a GdkWindow is created when the GdkWindow is created. GtkWindow sets the type hint on the GdkWindow right after creating it, which is too late -- the HWND is already there and using the wrong class. Unless I'm missing something the patch above fails because of this problem.
Created attachment 81568 [details] [review] Experimental patch to implement drop shadows from type hints This patch (based on the patch from Dom Lachowicz) implements drop shadows based on the window type hint. To do this, I added a new function gdk_window_new_with_type_hint() that lets me pass the type hint in when the window is created. If this approach is acceptable I'll clean the patch up for inclusion.
I would suggest extending GdkWindowAttr instead; this can be done while preserving source and binary compatibility because of the use of a mask saying which fields are set. (Obviously any final patch for this would have to handle the other backends as well...)
Created attachment 81634 [details] [review] Updated patch Updated patch attached that modifies GdkWindowAttr instead. Added code to the other backends to get the type hint out of the GdkWindowAttr structure, but I don't have any way to test it. Added basic documentation of the changes but again I don't have a build environment for the docs. Could gdk_window_set_type_hint() be deprecated with these changes, or would that be too large a change to non-win32 applications?
Tested and applied to trunk and gtk-2-10.