GitLab

instead of a GdkNativeWindow. Also change gdk_selection_notify() API to
take a GdkWindow to match this change.

gdk_x11_window_lookup_window() calls are done by this function alreayd,
so no need to do them manually.

The client_pointer field in GdkX11DeviceManagerXI2 is not used anywhere.

We cannot totally ignore core key events, since XFilterEvent generates
those at times and relies on them having an effect.
https://bugzilla.gnome.org/show_bug.cgi?id=640965

It turns out that the gtk_grab_remove() can trigger a do_prelight()
call, which may end up changing prelight_node, and then the state
gets messed up. Moving the grab removal until after we're done with
button_pressed_node and prlight_node makes expanders work reliably.

One thing that is still not right is that the expander doesn't get
prelight again after the animation is done, if you manage to release
without any additional motion events.

https://bugzilla.gnome.org/show_bug.cgi?id=641039

... 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

It didn't work and did that by using APIs that are about to go away.

That ability didn't work for a while anyway, so removing client messages
doesn't hurt.

Client messages will not be handled by GDK3 anymore, so no need to test
them.

No need to run sophisticated functions to guess it.

The client message code is about to go away, so we need to use a
different way to get at ClientMessage output.

a) We advertise it for GdkFilterFunc
b) It's necessary to differentiate between different event types with
   multi-backend GTK.

Also remove the (de-facto unused) implementation from GtkWindow that was
only used for sockets/plugs.

If a selection looses its owner without a replacement, owner is
None, which we did not handle very well.

https://bugzilla.gnome.org/show_bug.cgi?id=641042

Dan Winship authored Jan 31, 2011 and Matthias Clasen committed Jan 31, 2011

https://bugzilla.gnome.org/show_bug.cgi?id=641059

See https://bugzilla.gnome.org/show_bug.cgi?id=641073

GtkTrayIcon depends on GtkPlug which is X11-specific.  This fixes the
build for Quartz.

I've decided that it is isn't feasible to make cell areas runtime-settable
in the time we have left before 3.0, therefore, I'm going with the
approach to allow init() functions to instantiate the default cell area
and issue a warning if a construct property is ignored.

This is not ideal, but it keeps existing icon view and combo box
subclasses working.

https://bugzilla.gnome.org/show_bug.cgi?id=639139

Mention key-repeat in key-press and fix a copy'n'paste in key-release docs.

The forall() loop was buggy as it was skipping items in the list when
the current item gets removed from the groups array as a result of
calling the callback (causing memory leaks).

Also updated documentation, closes bug 322926

https://bugzilla.gnome.org/show_bug.cgi?id=640487

As it was with the old style, when the Switch is in the "on" state the
trough should be using the selected background color.

Go back to 200ms, which is what we had in GTK+ 2.x.
Themes can change this, of course.

For keynav, we were still passing it the filter model.
https://bugzilla.gnome.org/show_bug.cgi?id=640698

The grabbed_keys might be NULL, so deal with that.
https://bugzilla.gnome.org/show_bug.cgi?id=641023

https://bugzilla.gnome.org/show_bug.cgi?id=640999

Use GdkWindow instead. This requires calling
gdk_x11_window_foreign_new_for_display(), so might cause a slight
performance penalty, but is required to be portable.