...so that we will include the correct gdkconfig.h, which would be
in $(srcroot)\gdk\ during the Visual C++ build.
Also prepare support for Visual Studio 2012 in this project, so it would
be easy to use a script to copy and replace the necessary items in the
Visual Studio 2010 project set to make it a Visual Studio 2012 set.
We must not release the GtkClipboardOwner in pasteboardChangedOwner
becaue we don't own a reference to ourselves (NSPasteboard does).
Instead, release the owner right after setting it, transferring
ownership to NSPasteboard
Also, fix repeated setting of the same owner by keeping the
owner around in GtkCLipboard, and re-use it if "user_data"
doesn't change. To avoid clipboard_unset()ting our own contents
in the process, add an ugly "setting_same_owner" boolean to
GtkClipboardOwner, set it during re-setting the same owner,
and avoid calling clipboard_unset() from pasteboardChangedOwner
if it's TRUE.
The Visual C++ project files for GTK+-2.24.x need to be updated as the
Windows theme engine (libwimp) currently has to be built as a DLL.
This adds the Visual C++ 2010 project file to build libwimp as a
standalone module/DLL, and the property sheets, .sln file and
gtk.vcxprojin/gtk.vcxproj.filtersin/install.vcxproj are updated
accordingly so that the needed stuff get built properly and go
to the proper places for the Windows Themes to work correctly
with the Visual C++ builds.
Thanks to nus for pointing this out.
The Visual C++ project files for GTK+-2.24.x need to be updated as the
Windows theme engine (libwimp) currently has to be built as a DLL.
This adds the Visual C++ 2008 project file to build libwimp as a standalone
module/DLL, and the property sheets, .sln file and gtk.vcprojin are updated
accordingly so that the needed stuff get built properly and go to the
proper places for the Windows Themes to work correctly with the Visual C++
builds.
Thanks to nus for pointing this out. Visual C++ 2010 projects files will
be updated in the next 1-2 days.
pasteboardChangedOwner is not called as reliably as we'd want to get it,
so keep track of [pasteboard changeCount] and drop clipboard ownership
when a change happened. Also better unset the clipboard content redundantly
in a few places rather than missing one, and reorder the code in
gtk_clipboard_set_contents() so that the new aggressive unsetting
won't unset the clipboard under our feet when we call
[pasteboard declareTypes].
Per the gtk-devel meeting on 2012/11/29, we'll not have a UI in the file chooser dialog
to select between those modes. Instead, we'll show that key in gtweaktool.
This reverts commit 7860500bc6.
Both flashing a window and setting the window opacity were using
incorrect declarations for function pointers. They were missing the
WINAPI annotation as defined in windows.h. As a result, the stack
could be corrupted when these functions were invoked.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=689235
Be a bit more careful in get_pango_attr_list() and
get_utf8_preedit_string() to ensure that the client_window is properly
created before proceeding, to avoid access violation/segfault crashes on
Windows with IME installed, especially when running the pickers demo.
https://bugzilla.gnome.org/show_bug.cgi?id=682919
(cherry picked from commit a866ed7378)
In gtkimcontextime.c, use gdk_win32_window_get_impl_hwnd() to get to
the impl's existing native window instead of GDK_WINDOW_HWND() which
implicitly ensures a native window for the widget itself. This seems
to work around whatever GDK problem with native subwindows and fixes
the bug.
Activate the "hides on deactivate" behavior for splashscreens,
torn-off menus, utility windows, tooltips and notifications: when
another application is brought to the front, these windows are hidden
so as not to obscure it. This is the expected behavior for
application-specific floating windows on OS X.
When GTK+ runs with inputim-ime.dll module, there is NULL
pointer reference. Because "context_ime->client_window" may
be NULL in gtk_im_context_ime_reset.
https://bugzilla.gnome.org/show_bug.cgi?id=644906
(cherry picked from commit 74f57ee04d)
Based on a patch from Paul Davis, inject synthetic enter events directly
into the Quartz event stream, instead of trying to synthesize them in GDK.
This seems to magically fix most combo box popup weirdness, I guess
some code is relying on a specfic order of events, or any other state
imposed by the "proper" code path of events coming in the usual way.
The patch also removes _gdk_quartz_events_send_enter_notify_event()
which is now obsolete.
so they can appear on top of popup menus. Also, reorder the switch()
statement in window_type_hint_to_level() so it resembles the stacking
order, to avoid confision like this in the future.
The call to scrollRect: must be accompanied by a call to redraw the
newly exposed area, otherwise the scrollRect: will have no effect.
Secondly, compute the newly exposed area correctly.
Thirdly, also expose the lower window border or the area moved from
the lower window border if applicable, to make sure rounded corners
are properly drawn or don't leave garbage.
Don't try to handle button press events on the window frame, they
have out-of-window coordinates. Also, break grabs on such events
so popup menus go away.
Patch from Kristian Rietveld, fixes bug 684419.
which does not really have a different effect than the previously
used NSPopUpMenuWindowLevel, but is what all code examples I found
are using, and it does make more sense.
Application code can set shortcut folders that are already bookmarks.
This code causes the bookmarks to be refreshed after the shortcut is
added removing any possible bookmark duplicates
https://bugzilla.gnome.org/show_bug.cgi?id=577806
Don't just unref the completion_store, call discard_completion_store()
instead which also unsets it as the GtkEntryCompletion's model. Fixes
bug 681845 and probably some others, because the situation in this bug
is completely common.
because the user_data is the GtkTextView. This used to crash when the
text view got destroyed, and the buffer was used for another view.
Fixes bug #652204.
Will read from old location if new location isn't found, and will always
write back to the original location the file was read from.
Adapted from commit ceb3fecd11 on the
master branch, based on a patch from
William Jon McCann <jmccann@redhat.com>
GdkPixmapWin32 allocates a cairo_surface manually for non-foreign
pixmaps, instead of letting GdkDrawableWin32 create on on-demand.
However, the pixmap created surface is a strong ref, rather than the
weak ref created by gdk_win32_ref_cairo_surface() so we can't rely
on _gdk_win32_drawable_finish to actually free it. So, we have to
manually free it when we finalize or we leak it.
https://bugzilla.gnome.org/show_bug.cgi?id=685959
Before we used a window's background color, which resulted in corrupted
display in some cases, presumably because we didn't reset the active
pattern. This patch seems to eliminate the observed corruption.
