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 757324 - win32: handle WM_DISPLAYCHANGE globally
win32: handle WM_DISPLAYCHANGE globally
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
3.17.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-10-29 16:29 UTC by Paolo Borelli
Modified: 2015-10-31 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (4.52 KB, patch)
2015-10-29 16:30 UTC, Paolo Borelli
committed Details | Review

Description Paolo Borelli 2015-10-29 16:29:27 UTC
Instead of handling WM_DISPLAYCHANGE on every GdkWindow, only handle it on an ad-hoc hidden window we create when opening the display.

This has two reasons:

 1) we want emit the display::size-changed signal even if there are no windows currently open

 2) we want to emit the signal just once and not once for every window


The patch has some questionable coding style (the case with braces, the split in an "inner" event function, etc, but I kept it like that since it is exactly the same as it is done for the other event win32 handling functions)
Comment 1 Paolo Borelli 2015-10-29 16:30:38 UTC
Created attachment 314416 [details] [review]
patch
Comment 2 LRN 2015-10-29 16:51:15 UTC
It does not call UnregisterClass() anywhere. If the DLL in which RegisterClass() is called can be unloaded without terminating the application, then UnregisterClass() should be used.

Other than that everything seems to make sense.
Comment 3 Paolo Borelli 2015-10-29 17:58:35 UTC
Do you have any suggestion on where we could call unregister? maybe display (or screen) dispose?

Note that the clipboard stuff also creates a window that is not unregistered anywhere, I guess that's a bug too
Comment 4 LRN 2015-10-29 18:24:58 UTC
This is not a problem if libgtkwhateveritis.dll can't be unloaded (consult with GObject people on the topic of unloading DLLs that use GObject).
Comment 5 Paolo Borelli 2015-10-29 18:53:10 UTC
<pbor> mclasen, Company: is unloading gtk supported these days?
<Company> no
<mclasen> unloading ?
<Company> you can't unload GTypes
<mclasen> as long as you don't want to reload it, ever, it might be ok
<pbor> just asking since it affects a win32 patch... if we care I need to find a way where to UnregisterClass
<Company> just don't g_type_class_ref (g_type_get_children(G_TYPE_OBJECT)[n])) !
<pbor> otherwise I just do not do it
<Company> don't do it
<Company> people can think about unregistering win32 stuff once they unloaded GTK on Linux
<pbor> fine with me
<pbor> calling UnregisterClass in display::dispose would not be hard
<pbor> just wondering if it is worth it
<mclasen> it isn't

So I'll take that as a no.

We can always fix things up if someone complains
Comment 6 Paolo Borelli 2015-10-31 14:32:28 UTC
I pushed the patch (slightly amended).