Prevent the new window dragging code from interfering with
selection of colors on button release, by handling button
presses we care about instead of letting them bubble up to
the window.
Partial fix for
https://bugzilla.gnome.org/show_bug.cgi?id=695493
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
Support long press for customizing, and short press for
selecting/activating. This is simpler than the generic
press-and-hold support in the multitouch branch; we don't
display any feedback, and the timeout is currently hardcoded
to 1 second.
Instead of having an input/output GdkWindow, make the widget no-window,
and use a separate input-only window for events, and paint on the parent
window directly.
Instead of GtkDrawingArea, since that calls in realize
gtk_style_context_set_background(). We don't want that to happen, given
that we do all the painting ourselves in _draw().
Instead of calling gtk_render_check() there, just render a symbolic
icon, falling back to a built-in one if the icon is not available.
Also, add a style class for the active badge on the swatch:
"color-active-badge".
Themes might want to set different colors on the badge if the displayed
color is light or dark. Use a style class for this when we set a color
on the swatch.
Rename get/set_color to get/set_rgba and show_alpha to use_alpha,
to match existing GtkColorButton API and let GtkColorButton implement
GtkColorChooser.
