Since GLib ≥ 2.41, attempting to release an unlocked mutex will abort(),
as it happens on most systems already.
Given the lack of proper documentation on how to use GDK with threads,
there is code in the wild that does:
gdk_threads_init ();
gdk_init ();
...
gtk_main ();
instead of the idiomatically correct:
gdk_threads_init ();
gdk_threads_enter ();
gtk_init ();
...
gtk_main ();
...
gdk_threads_leave ();
Which means that gtk_main() will try to release the GDK lock, and thus
trigger an error from GLib.
we cannot really fix all the wrong code everywhere, and since it does
not cost us anything, we can work around the issue inside GDK itself, by
trying to acquire the GDK lock inside gdk_threads_leave() with
trylock().
https://bugzilla.gnome.org/show_bug.cgi?id=735428
Although I can't find explicit documentation for clipboard pointer, it
seems to be possible to modify clibpoard memory without side-effects.
According to MSDN,
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366596%28v=vs.85%29.aspx
"The global and local functions are supported for porting from 16-bit
code, or for maintaining source code compatibility with 16-bit
Windows. Starting with 32-bit Windows, the global and local functions
are implemented as wrapper functions that call the corresponding heap
functions using a handle to the process's default heap."
"Memory objects allocated by GlobalAlloc and LocalAlloc are in private,
committed pages with read/write access that cannot be accessed by other
processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is
not actually shared globally as it is in 16-bit Windows. This value has
no effect and is available only for compatibility. "
https://bugzilla.gnome.org/show_bug.cgi?id=711553
It may happen that the received clipboard data is empty, but
if it's of type image/bmp, gtk+ will crash:
gdk_property_change: 00030AD4 GDK_SELECTION image/bmp REPLACE 8*0 bits:
... delayed rendering
gdk_selection_send_notify_for_display: 00030AD4 CLIPBOARD image/bmp
GDK_SELECTION (no-op)
_gdk_win32_selection_convert_to_dib: 1252003C image/bmp
Program received signal SIGSEGV, Segmentation fault.
0x749a9f40 in msvcrt!memmove () from C:\Windows\syswow64\msvcrt.dll
Thread 1 (Thread 2248.0x1b34):
target=0xc07b) at gdkselection-win32.c:1292
at gdkevents-win32.c:3498
wparam=8, lparam=0) at gdkevents-win32.c:232
message=773, wparam=8, lparam=0)
at gdkevents-win32.c:263
C:\Windows\syswow64\user32.dll
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
wparam=0, lparam=-1687549457)
at gdkevents-win32.c:248
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
https://bugzilla.gnome.org/show_bug.cgi?id=728745
Originaly the size of the window based on the client area size has
been calculated first and then variables dwStyle and dwExStyle have
been changed. Thus the window size has been calculated for different
windows type then eventually used when calling CreateWindowEx. This
caused for example the Gimp tool windows to have different size than
formerly saved in session. The whole code calculating the window size
is moved after the last adjustment of dwExStyle variable in this patch.
Signed-off-by: Hans Breuer <hans@breuer.org>
Only one bitmap can be selected into a device context. Using the
DIB created by cairo consumes the one opportunity, so every further
SelectObject into the same DC in GDK code will fail.
Can not find in the changelog entry why it was disabled at all,
see: http://git.gnome.org/browse/gtk+/commit/?id=3f4c73
The ill effect is somewhat hidden: if you try to copy images
via clipboard only the first one is pastable, i.e. Gdk keeps
the reference to the first image and provides it for later
paste.
Put dialogs and utility windows in the same level as normal and
toolbar windows so that Gtk can control their stacking instead of
forcing them, rather unnaturally, to be on top of all other windows,
even other application windows, even when another application has
focus.
Since update_windows list is a static variable in GdkWindow.c which
contains pointers to windows which needs to be updated, it can happen
that it contains a pointer to a window even after quit from a gtk_main().
If another gtk_main() is called in the same process it tries to process
windows in the list which leads to a crash.
Correct reference count handling of added windows prevents such applications
from crash.
https://bugzilla.gnome.org/show_bug.cgi?id=711552
The MINMAXINFO struct was being populated based upon geometry hints when
GDK_HINT_MAX_SIZE flag was enabled, then promptly having its values blown
away with default values.
https://bugzilla.gnome.org/show_bug.cgi?id=711110
If gdk_pixmap_new() fails (e.g. CreateDIBSection() failure) we end up
g_object_unref()-ing the temporary GdkPixmap, and we do this before having set
the drawable_impl->hdc and drawable_impl->hdc_count. Now, this could have just
been a couple of warnings being dumped, but instead it really crashes the
application because in win32-specific GdkDrawable's finalize() we assert if
drawable_impl->hdc_count is not zero:
Gdk:ERROR:gdkdrawable-win32.c:2047:_gdk_win32_drawable_finish: assertion failed: (impl->hdc_count == 0)
In order to avoid this crash, we make sure we don't decrement the hdc_count in
the GdkPixmap's finalize() unless we have it set first (i.e. we avoid hdc_count
going down to -1).
https://bugzilla.gnome.org/show_bug.cgi?id=699236
When _gdk_windowing_create_cairo_surface() gets called, we should always create
a fully new cairo surface, instead of just referencing the available one, which
may already be finished (i.e. in CAIRO_STATUS_SURFACE_FINISHED state).
A new user_data key is added to the surface to explicitly release the acquired
DC when the surface is destroyed, independent to the user_data key added to
clear the impl->user_data pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=695636
because nobody has called gdk_keymap_get_for_display() before.
Now we simply make sure the default display's keymap exists
if somebody calls any gdk_keymap_*() function with a NULL
keymap (which is an allowed value).
and not on each keystroke, which for some IMs apparently caused a full
update on each keystroke, not just a check for changes. Patch from
Takuro Ashie, bug #698183.
window_type_hint_to_level(): applied patch from Paul Davis which moves
dialogs to NSFloatingWindowLevel. This is not quite the perfect
solution, but it's a pragmatic fix that makes apps which have both
window types much more usable, and prevents dialog from disappearing
under an application's main window.
Particularly look at the source image's byte order when making a
screenshot of the "root window" (which is the window stack). Make
the code more generic so it can handle all sorts of pixel formats.
Ignore X11 errors from querying state of unplugged input devices.
GTK+ 3 handle this better with hotplugging support in XInput 2, but
this is working workaround for avoiding ugly crashes and data loss
with GTK+ 2.
GetLastError() should be called immediately after the failure, so call
WIN32_GDI_FAILED() just after the CreateDIBSection() error, not after
ReleaseDC().
https://bugzilla.gnome.org/show_bug.cgi?id=698563
If gdk_window_flush_outstanding_moves() creates new update area
we handle this directly in the same draw to avoid flashing.
This mainly affects win32 as X11 does its exposes from moves async.
However, its important for win32 since ScrollDC seems to sometimes
invalidate (and not copy) unexected regions.
http://bugzilla.gnome.org/show_bug.cgi?674051
Rather than set the window update region and repaint this region
when we get a WM_PAINT we just directly add it to the update
region. No need to roundtrip via win32.
This lets us also make sure we do this drawing in the same update
cycle. This seems especially important on Win7, because ScrollDC
seems to act kind of weird there, not using bitblt in areas where
it seemingly could, which makes scrolling look really flashy.
http://bugzilla.gnome.org/show_bug-cgi?id=674051
If the do_move_region_bits_on_impl causes updates they will
only be affected by the moves we haven't done yet.
We do this by making sure the outstanding_moves list is uptodate
on ever iteration of the loop.
gdkwindown-win32.c included windows.h directly rather than via gdkwin32.h
which broke the build for me at least. Instead rely on it being included in
gdkwin32.h and things work right.
