The function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
This function can be used to find the GdkDevice wrapping
an XInput2 device ID. For core devices, the Virtual Core
Pointer/Keyboard IDs (2/3) may be used.
This function can be used to find out the XInput2 device ID
behind a GdkDevice, mostly useful when you need to interact
with say Clutter, or raw libXi calls.
This symbol needs to be exported for GDK (Win32) so that the
runtime checks for Win32 backend usage can be done on
MSVC-compiled versions of GTK+ too.
I did not add the corresponding symbols for the other backend
though-they are probably exported automatically by GCC AFAIK.
This is done to make commit
9db4accf9c
work on MSVC
The metacity theme format allows to use colors from the current
GTK+ theme in window decorations. Since GTK+ now gained support
for dark theme variants, window managers using that theme format
(metacity, mutter, compiz via gtk-window-decorator) should be able
to use colors from the correct variant; so in case a variant is
requested, export it in the _GTK_THEME_VARIANT property on
toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645354
The previous function gdk_drag_get_protocol_for_display() took native
window handles, so it had to be changed. Because it didn't do what it
was named to do (it didn't return a protocol even though it was named
get_protocol) and because it doesn't operate on the display anymore but
on the actual window, it's now called gdk_window_get_drag_protocol().
... and all APIs making use of it.
That code like it hasn't been touched in years, Google codesearch
didn't find any users and most importantly it's a horrendous API, so
let's just make it die instead of having to port it over to
non-GdkNativeWindow usage, which would be required for multi-backend
GDK.
http://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00049.html
There's no usecase for them, so remove them before we have to commit to
keeping an API.
Make the hooks private for now, actually removing them will come in
followup patches.
Its usecase was GERD - http://testbit.eu/~timj/historic/gerd/ - and that
project is long since dead.
I couldn't find any app using it after asking around and googling either.
Its usecase was GERD - http://testbit.eu/~timj/historic/gerd/ - and that
project is long since dead.
It has been superseded in GTK 2.2 by GdkDisplayPointerHooks anyway.
There are sure regressions but basic stuff seems to be working
again after all the API breakage done with comments like
"Win32 and Quartz need to be ported still."
Move everything dealing with compound text to be X11 specific
Only gdk_text_property_to_utf8_list and gdk_utf8_to_string_target
are kept across backends, so add vfuncs for these.
Also, remove the non-multihead-safe variants of all these.
These functions were trivial g_spawn wrappers in all backends
except for X11, and they can be easily replaced by
g_app_info_create_for_commandline + GdkAppLaunchContext.
Add a GdkDisplay::get_app_launch_context vfunc, and a
gdk_display_get_app_launch_context that for X11 returns a subclass.
For win32 and quartz, the implementations were trivial, so we
just return a new GdkAppLaunchContext without subclassing. Since
the type of the context now depends on the display,
gdk_app_launch_context_set_display is deprecated.
The old functions to get core pointer and devices list are gone as
well. This slice is entirely replaced internally by multidevice
handling and may just go.
This function will enable events for all devices of a given
GdkInputSource, either these available at the time of the call,
or these that are connected in the future.
gdk_enable_multidevice() has been replaced with gdk_disable_multidevice(),
so applications may call that function if they want to go back at the
previous behavior.
There would be usually little reasons to call that function, unless the
application is doing X calls itself that count on old fashioned core
devices.
