An event filter may add or remove filters itself. This patch does
two things to address this case. The first is to take a temporary
reference to the filter while it is being used. The second is
to wait until after the filter function is run before determining
the next node in the list to process. This guards against
changes to the next node. It also does not run functions
that have been marked as removed. Though I'm not sure if this
case can arise.
https://bugzilla.gnome.org/show_bug.cgi?id=635380
Backport of 323df2b2800383832ed3c2e43626f2c6821c33ec to
the gtk-2-24 branch by Wolfgang Ulbrich.
When using the implicit paint pixmap, always draw to the same surface
(the standard one for the pixmap) each time rather than creating a new
one each time. This is both more effective and more natural.
It also fixes a redraw issue on win32, where using multiple surfaces
on the same HDC sometimes causes issues. This seems to be due to
leftover state on the HDC from previous surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=741060
Commit 85f2a721cf introduced an unconditional call to
gtk_widget_get_direction(). This does not work for 'foreign'
uses of the theme engine, e.g. in Qt, where widget is NULL.
This was reported as a crash in Fedora here:
https://bugzilla.redhat.com/show_bug.cgi?id=924683
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
The function gtk_drag_set_icon_pixmap() triggered failing assertions. This was because it called the function gdk_window_get_screen(mask), where "mask" is a pixmap, but not a window.
https://bugzilla.gnome.org/show_bug.cgi?id=735005
As the Visual Studio 2012/2013 are only slightly different from the Visual
Studio 2010 projects, we can provide support for them by using scripts to
copy the Visual Studio 2010 projects, and update the specific parts as
necessary. This is being provided to help people still needing GTK+-2.x
and also to help them to transition to GTK+-3.x easier.
Thus, there would be little maintenance overhead for these as only the 2010
projects need to be kept up-to-date as a result. This might change when we
do get the stack working with WinRT/Metro, but that's going to be another
totally different issue.
We need to enclose paths containing $(BinDir) with double quotes as it
points to something like c:\foo\gtk+-x.yy.zz, which the copy command on
Windows does not like "+" in paths unless enclosed in quotes.
Since large images are in the icon cache, and apps don't tend to use that
many icons anymore, simply don't include image data and instead make apps
load files from disk. Additionally, since they're stored in GdkPixbuf data,
that means that we have to first convert them either to a cairo_surface_t,
which requires converting pixel data to be premulitplied, or an OpenGL
texture, which requires a whole GPU upload anyway.
So, even with the icon cache, the goal of icons through zero-copy, mmap()'d
data from disk just isn't doable with the icon cache format we have. The
icon cache on my disk is nearing 100MB, since we include a bunch of
high-resolution application icons, that I doubt would be used by apps at all.
Removing this inefficient pixel data makes memory usage for all applications
go down, with no speed loss.
The icon cache also, however, has an index of what icons are in each folder,
which prevents a readdir() and allows GTK+ to know what icon is where without
having to do a bunch of stat(); calls. Keeping this data is good for GTK+,
so we should still keep the index.
It doesn't make sense to remove any code for mapping pixel data from the icon
cache. There's a plan in the works to have a symbolic icon cache that does
pixel math on 16x16 icons to prevent slow SVG rendering. 16x16 pixels are
fairly small, and such images are flat colors, which should compress easily,
so the icon cache would be worthwhile here. So let's keep the code around
in preparation for that case.
https://bugzilla.gnome.org/show_bug.cgi?id=721895
Currently, due to the way that Visual Studio 2010+ projects are handled,
the "install" project does not re-build upon changes to the sources, as it
does not believe that its dependencies have changed, although the changed
sources are automatically recompiled. This means that if a part or more
of the solution does not build, or if the sources need some other fixes
or enhancements, the up-to-date build is not copied automatically, which
can be misleading.
Improve on the situation by forcing the "install" project to trigger its
rebuild, so that the updated binaries can be copied. This does trigger an
MSBuild warning, but having that warning is way better than not having an
up-to-date build, especially during testing and development.
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
As we are likely to have GTK+-2.x around for some time, revamp the Visual
Studio 2010 projects like what was done for rest of the GTK+ stack, namely:
-Split the property sheets, in a way like what was done for the rest of the
stack. Also clean up the resulting property sheets a bit, and update the
projects to use these property sheets.
-Use UNIX line endings for all projects and property sheets, to ease future
application of patches.
-Make the copying of config.h.win32 and gdkconfig.h.win32 into custom build
rules, so that they may be removed properly and re-copied during change
and update.
-Add a PlatformToolset tag, so if we want to support building with Visual
Studio 2012/2013, the transition can be done quite easily with a script,
such as what is now being done for the Visual Studio 2012 projects for
GLib.
As we are likely to have GTK+-2.x around for some time, revamp the Visual
Studio 2008 projects like what was done for rest of the GTK+ stack, namely:
-Split the property sheets, in a way like what was done for the rest of the
stack. Also clean up the resulting property sheets a bit, and update the
projects to use these property sheets.
-Use UNIX line endings for all projects and property sheets, to ease future
application of patches.
-Make the copying of config.h.win32 and gdkconfig.h.win32 into custom build
rules, so that they may be removed properly and re-copied during change
and update.
Similar updates will be applied for the Visual Studio 2010 projects ASAP.
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.
