On popover_unmap(), perform the gtk_widget_unmap() call last, so the
GtkWindowPopover data is ensured to be alive throughout the function
if the popover widget is destroyed right on ::unmap.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
Now that this is split in two separate gestures, both must be reset
when the WM grabs the pointer. Also, do on resize drags like on move
drags, and claim the gesture before resetting, so the ownership is
properly transferred across any other widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=745969
This reverts commit fb9a6bb6d8.
In a recent test, I've found that Xfce and Mate now support
this, so they will not be affected by this requirement. And
adding the check back will solve the 'client-side shadow'
problem in KDE.
Postpone until the last moment whether the target widget still
potentially uses updates from this sequence, or window dragging
actually applies because all gestures on the target went to denied
state.
This fixes window dragging on empty space in a headerbar that is
contained in a paned (as in e.g. gedit).
https://bugzilla.gnome.org/show_bug.cgi?id=745562
The gesture is hooked to the capture phase, so it works for buttons in
header bars and whatnot. In order to be friendly to the widget it is
capturing events from, an ugly hack is in place to avoid capturing
events when the target widget has a gesture that would consume motion
events.
is_visible() wasn't the right check to perform here before unmapping,
and gtk_widget_unmap() already avoids being doubly called by checking
gtk_widget_get_mapped() anyway.
If the grab belongs elsewhere, the window won't claim the sequence right
away. The sequence may still be claimed afterwards when window dragging
starts, but simple clicks won't be consumed this way.
This makes it possible to close popovers when clicking on the title region,
while still permitting touch/button 1 interaction for every other purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=743257
On the wayland backend, set up GDK_WINDOW_SUBSURFACE windows
for popovers. In the popover code, the popover-relative-to-parent
calculation had to be tweaked, and it's been made to always prefer
the given popover position, since there's no sizing limitations.
https://bugzilla.gnome.org/show_bug.cgi?id=738891
Currently we only take into account the window GActionGroup for
activating the accels.
However, the application could have some custom GActionGroup in the
chain of focused widgets that could want to activate some action if
some accel is activated while that widget is focused.
To allow applications to set accels on widgets that use custom
GActionGroups, simply use the muxer of the focused widget, which
already contains the actions of the parents.
https://bugzilla.gnome.org/show_bug.cgi?id=740682
This event might not have an action yet, but certainly accounts, and
should be triggering recognition.
This fixes a crash when attempting to drag CSD windows through touch. As
since cfaec2d2f5, gtk_gesture_single_get_current_sequence() would
rightfully return NULL if the gesture didn't enter recognition, making
event lookup fail.
Under wayland, the compositor doesn't have a 'overall window alpha'
knob, we just need to add the alpha to the buffers we send.
Client-side alpha, if you want to call it that.
Implement this by reusing the existing alpha support for non-toplevel
widgets. As a side-effect of the implementation, windows with RGBA
visual under X will now also use per-pixel alpha, instead of
overall alpha.
When the window is on a non-default screen, popover_realize
ended up passing a visual and a parent_window from different
screens into gdk_window_new, which doesn't work. Fix it by
using the visual of the parent window.
When a new screen is set on a window, we unrealize it, to
recreate all the resources. But we don't reset the client_decorated
flag, so realize() doesn't call create_decoration() - which makes
sense, since the decoration already exists. But the side-effect
of create_decoration() is to select the rgba visual, and visuals
are per-screen.
Fix this by looking for the rgba visual in set_screen(), and
replacing it with the rgba visual for the new screen, if necessary.
When gtk_window_set_titlebar (win, NULL) is called, we were taking
an early exit and forgot to re-map the window. This does not normally
happen in practice, but glade is about to get a 'csd' switch which
lets one toggle back and forth between titlebar and no titlebar.
If the menubar has an app-menu popover, and it is shown at the time of
disposing the window, it will attempt to transfer focus back to the
previous focus widget when undoing modality, even though the dispose()
code already did set_focus(NULL) previously.
At the time the popover is removed, there aren't many hints as to whether
the toplevel or the focus widget are being destroyed (ie. not still under
in_destruction), so just swap the order of these two calls.
For every other popover, this would all happen within dispose/destroy,
which is handled better.
Binding signals can return a boolean indicating whether they
handled the event. Use that here and return FALSE if the
inspector keybinding is disabled.
Instead of hardcoding these actions, consult the settings.
Note that not all of the actions supported by gnome-shell are
implemented here, only maximize, minimize, lower, and menu.
https://bugzilla.gnome.org/show_bug.cgi?id=729782
This gives an opportunity for implementations to handle these events
differently, instead of hardcoding the WM-triggering behavior.
gtk_window_event() only forwards events for WM management if the event
widget is not the window (ie. caught when bubbling), so is safe to be
called here without triggering gtk_window_handle_wm_event() twice.
This commit is an adaption to master of
https://bugzilla.gnome.org/show_bug.cgi?id=736702#c1 by Cosimo Cecchi.
Otherwise, they might not be properly set before the window is mapped.
For the opaque region and border window, it means that they won't get
set before the next size allocation, which tends to not be a bit deal.
For the shadow width, though, _GTK_FRAME_EXTENTS has a different meaning
when it's set before the window is mapped, so we need to make sure that
it's properly set when the window is mapped.
When GtkApplicationWindow has a menubar, we don't chain up
to the GtkWindow size_allocate, which used to position the
popovers. Move that to _gtk_window_set_allocation() which
is always called by GtkApplicationWindow.
https://bugzilla.gnome.org/show_bug.cgi?id=736205
This must be called while the window is not realized yet, and sets the
GdkWindow that will be used for the next GtkWindow's realize/unrealize
cycle. The GtkWindow takes ownership on the GdkWindow, and as such it
will be destroyed when the widget is unrealized.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
This is a rather hackish way to let GTK+ widgets declare popup windows
as subsurfaces, so they may work on wayland without the need of xdg_popup,
and without many changes yet on the GTK+ side.
https://bugzilla.gnome.org/show_bug.cgi?id=695504
Popovers may get relocations optimized away if only x/y changed
in the GtkAllocation. So make sure the toplevel updates popover
positions on all situations.
https://bugzilla.gnome.org/show_bug.cgi?id=729140
If the same position is requested on a popover, it should at least ensure
the window is realized and raised, even if no resizes are queued on the
content. Otherwise other widgets being mapped might raise the windows over
the popover's if its original position is unchanged.
https://bugzilla.gnome.org/show_bug.cgi?id=734129
So far, gtk_window_set_focus just did not work when called on
a hidden window. Change it to record the desired focus widget
for hidden windows, and apply it when the window gets shown.
This is similar to how we tread other window properties that
can't be set before the window is realized, like maximized
or fullscreen.
This is related to
https://bugzilla.gnome.org/show_bug.cgi?id=734033
Don't shadow existing variables. Instead of sharing the allocation and
then overwriting the width/height when convenient, declare it in the
block we use it in, as, really, the three different paths are all
extremely different, and there's no sense in sharing the variable.
It's hard to figure out what the "expected_reply" means except under
close examination -- it's actually talking about whether this was a
reply to a ConfigureRequest or not. The inversion in the check doesn't
help either.
Make the code cleaner by moving it above the freeze/thaw case, and
making the check more explicit and without a confusing variable. If we
haven't sent any ConfigureRequests out, then it must be a gratuitous
ConfigureNotify.
Keep Ctrol-Shift-D as a straight toggle-the-inspector keybinding,
but make Ctrl-Shift-I always bring up the inspector, and point
it at the widget under the pointer.
Resize grips were introduced for GNOME 3.0, before we had any of the
"new GNOME app" features like invisible borders and CSD. With OS X 10.6
and 10.7, Apple has replaced the classic grips in their applications
with invisible borders as well.
New GNOME app designs don't use resize grips anymore and the new
default theme for GTK+, Adwaita, disables them entirely by forcing their
width and height to 0.
They're past their time. Remove the code to support them. This can
always be reverted if some app relies on them.
When showing and hiding the inspector window repeatedly without
dismissing the dialog, we were hiding the inspector, but not
the dialog, leading to a confusing user experience.
https://bugzilla.gnome.org/show_bug.cgi?id=732443
Since we have a paint clock, we shouldn't be sending out EXPOSE events
for OR windows inside the ALLOCATE cycle. The idea here was that we
would have to wait for a map to get an OR window to paint to, but since
then this has been abstracted away inside GDK and the paint clock.
We already update the grip position in _gtk_window_set_allocation, which
is done through the size_allocate above. Receiving a ConfigureNotify
also won't ever change a grip's visibility, so there's no point in
refreshing it.
This way plain clicks can be handled in gtkmain through the usual delivery mechanism,
and get possibly handled too by widgets holding a GTK+ grab. If window dragging is to
be started, the sequence will be claimed (and a grab will happen afterwards), notifying
properly the grabbing widget that event delivery was interrupted.
This makes it possible to dismiss popovers by clicking on window headerbars, while
still making it possible to drag the window with the popover opened.
For csd override-redirect windows, we don't set up resize handles,
but we were not ignoring the margin in all places, causing some
size calculations to go wrong.
This commit makes it possible to use client-side decorations for
override-redirect windows by calling _gtk_window_request_csd()
before realizing the window. Since the wm won't do interactive
resizing for us in this case anyway, don't bother creating
the border windows we use for this purpose on regular toplevels.
To make this accessible to themes, we set a "csd" style class
on client-side decorated windows. With this, .window-frame.csd.menu
can be used to define the shadow for csd menus, and .menu can be
used to define a border for menus under non-composited wms.
https://bugzilla.gnome.org/show_bug.cgi?id=731187
Every button press/release event reaching the the multipress gesture in GtkWindow
and happening in the "title" region must be handled, regardless of the event widget.
Children there wanting the event(s) for themselves are (and were always) expected
to stop event propagation.
So the only place to check for the event widget's "window-dragging" style property
is the "content" region, which matches the pre-gestures behavior.
This fixes some issues with sequences being mistakenly claimed (and events not
propagated further) on situations it shouldn't.
The multipress gesture must react to either direct events on the
GtkWindow (special cased through _gtk_widget_check_handle_wm_event),
or bubbled events from child widgets. Ensure bubbled events go
through the gesture, those are fed manually to make sure events are
only handled once, in either one or other place. The implicit grab
will ensure that doesn't change mid-action.
The events to those are fed outside the regular event propagation scheme,
through _gtk_window_check_handle_wm_event(), so set the controller to
GTK_PHASE_NONE so events aren't processed first manually, and then
automatically.
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
A multipress gesture is used to control all this, replacing
single/double click custom code, and triggering window dragging
when the multipress is stopped, yet active (ie. the sequence remains
pressed).
This avoids a bunch of policy problems with deciding how to lay
out the window menu under different WMs.
For now, we use the special event _GTK_SHOW_WINDOW_MENU, but we
hope to have this standardized in wm-spec quite soon, as KDE wants
it as well.
With the keybinding, it is possible that users may trigger the
inspector unintentionally. Show a dialog that informs them about
whats going on and gives them a chance to back out.
The warning dialog can be bypassed with the
org.gtk.Settings.Debug inspector-warning setting.
Moving the inspector into libgtk lets use reuse internals without
having to add public API for everything or inventing awkward private
call conventions.
https://bugzilla.gnome.org/show_bug.cgi?id=730095
We are keeping references on the widget we are handling as we
are iterating up, but that doesn't protect us against the entire
tree being axed from inside gtk_widget_handle_event.
https://bugzilla.gnome.org/show_bug.cgi?id=727644
We are getting bug reports from people who are irritated that
dialogs now have 'double headers' under any wm but gnome-shell.
As an example, xfwm4 seems to do ok with csd windows, and
on balance it seems better to have some invisible border issues
than to have double headers.
https://bugzilla.gnome.org/show_bug.cgi?id=727414
Setting windows undecorated was broken by some of the recent
shadow width changes. We need to ensure that shadow width is
zero for undecorated windows, then things work again.
If the delete event ends up destroying the widget, unsetting
priv->delete_event_handler will happen on invalid memory, so
unset it before the widget is possibly destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=726825
We did not set an input shape on the window, so the region outside
the invisible border where we draw the outer edges of the shadow
were still part of the window, as far as clicks and cursors were
concerned. Fix this by setting an input shape that makes all clicks
outside of the resize borders go through to the underlying window.
https://bugzilla.gnome.org/show_bug.cgi?id=726125
As those are internal children, there's no signal that GtkWindowAccessible
could catch when those are added or removed, so make GtkWindow use the private
GtkContainerAccessible methods to add/remove the child accessible when that
happens.
https://bugzilla.gnome.org/show_bug.cgi?id=725864
As discussed on desktop-devel-list [1], "There should be an intuitive,
consistent, immediate way to jump to the widgets that live in the
header bar." F10 has been suggested for this as it is already used to
active menubars.
F10 will focus the custom titlebar widget if the window has one and it
isn't already focused. If the titlebar widget doesn't exist or is
already focused then F10 focuses the menubar if there is one.
[1] https://mail.gnome.org/archives/desktop-devel-list/2014-February/msg00176.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=725141
It turns out popovers are already smart enough to cope with this
situation, so let popovers be internal children so things that rely
on gtk_container_forall(), like DnD, work without modifications.
https://bugzilla.gnome.org/show_bug.cgi?id=725727
c287845240 was trying to fix
the memory leak caused by popovers begin destroyed in
gtk_window_destroy before chaining up to gtk_widget_destroy,
which unrealizes the window, and would clean up the popover
windows if the popovers were still around.
Fix this in a better way by moving the popover destruction
after the chaining up, so we unrealize first, and then
destroy the popovers.
Also, make _gtk_window_remove_popover unrealize the popover,
for symmetry with _gtk_window_add_popover.
This should fix
https://bugzilla.gnome.org/show_bug.cgi?id=724921
Dragging windows was not working on widgets in the titlebar
region unless they had the window-dragging style property
set. Fix this by looking at the region for motion notify
events as well as for buton press events.
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
Heavy duty can prevent this idle function from being called before
the window is destroyed, so make sure that the source is removed
when the window is finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=723771
Since realize does a lot of the heavy lifting of setting up
csd, we have to re-realize the window if we go from no-custom
titlebar to a custom titlebar or vice versa.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
When gtk_window_set_titlebar is called, we need to set up
client-side decorations properly, and the easiest way to do
so is to realize the window again. Really, you should call
set_titlebar before the window is realized.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
GtkWindow has 4 (!) APIs for setting window icons, and we
have to try them all in the right order to find the right
icon. This commit makes it so, and keeps the icon list
manipulation inside gtkwindow.c by adding a private API
for getting a single icon at the right size.
https://bugzilla.gnome.org/show_bug.cgi?id=722515
When all popovers are removed on destroy(), if a popover is nested into
(eg. with relative_to within) another popover, the removal of one can
lead to the other being removed while the hashtable is being iterated,
which would lead to undefined behavior in further iterations.
Then, use a GList to store popovers, iterating can be made more resilient
on these situations, and unless on pathological cases there's not going
to be as many of those popovers as to cause performance decreases at the
times those are iterated.
The popovers may return keyboard grabs to previous widgets, so if
called after unsetting the focus, the window may be left with a
dangling GtkWidget that would cause crash at later dispose() calls.
Popovers are strange in the sense that they aren't attached to a
parent directly, they rely on the relative_to widget so the toplevel
is shared, and when they have a parent, it is the toplevel itself,
not relative_to. This also means that there are conditions where the
popover loses it's parent, so they must survive unparenting.
The previous code would be floating the last reference as soon as the
parent is gone, but it was non-obvious who'd own that reference. So
fix this situation by granting the ownership of popovers to their
relative_to widget, an extra reference may be held by the toplevel
when the popover has a parent, but the popover object will be
guaranteed to be alive as long as the parent lives.
This way, memory management of popovers is as hidden from the user
as regular widgets within containers are, users are free to call
gtk_widget_destroy() on a popover, but it'd eventually become
destructed when relative_to is.
This makes it possible to move/resize client-side decorated windows that are
otherwise obscured by a GTK+ grab somewhere else, either a popover within the
window itself or a modal dialog above the window.
Popovers are transient floating widgets that are confined to the
window space. These have their own GdkWindow that is set on top
of the regular window contents, so they can be used for popup menu
alike UIs with custom popup/popdown/grabs behavior.
With proper notifications, plus an accessor method for that state. This
allows client to just listen to notify::is-maximized instead of tracking
window-state-event.
https://bugzilla.gnome.org/show_bug.cgi?id=698786
This leads to disastruous results, since each menu is itself
in a GtkWindow, so holding down the menu key leads to a neverending
cascade of menus on top of menus.
https://bugzilla.gnome.org/show_bug.cgi?id=722106
The window-dragging code had a number of issues: The code was
starting a drag on every button press, never bothering to cancel
them. This leads to the odd hand cursor occurring between the two
clicks to maximize. We relied on GDK's multi-click detection, which
gives us triple-clicks when we really want sequences of double-clicks.
Lastly, we didn't propery restrict double-click handling to the primary
button, so e.g. if you had a window on an empty workspace, double-right
click on the titlebar would maximize it, which is not intended.
This commit solves all three problem by a doing our own double-click
detection, and only starting a drag when the pointer goes out of
'double-click range'. We change the way dragging is implemented for
menubars and toolbars to just letting events bubble up, so they
get the same behaviour as the titlebar. To make this work, we
have to select for pointer motion events in a few more places.
gtkapplication.c has turned into a bit of an #ifdef mess over time, and
many of the current checks are incorrect. As an example, if you build
Gtk for wayland, and exclude the X11 backend, much of the functionality
required by wayland (such as exporting menu models) will be disabled.
Solve that by introducing a backend mechanism to GtkApplication (named
GtkApplicationImpl) similar to the one in GApplication. Add backends
for Wayland, X11 and Quartz, with X11 and Wayland sharing a common
'DBus' superclass.
GtkApplicationImpl
|
/--------------+-------------------\
| |
GtkApplicationImplDBus GtkApplicationImplQuartz
|
/-----------+-----------------\
| |
GtkApplicationImplX11 GtkApplicationImplWayland
GtkApplicationImpl itself is essentially a bunch of vfuncs that serve as
hooks for various things that the platform-specific backends may be
interested in doing (startup, shutdown, managing windows, inhibit, etc.)
With this change, all platform specific code has been removed from
gtkapplication.c and gtkapplicationwindow.c (both of which are now free
of #ifdefs, except for a UNIX-specific use of GDesktopAppInfo in
gtkapplicationwindow.c).
Additionally, because of the movement of the property-setting code out
of GtkApplicationWindow, the _GTK_APPLICATION_ID properties (and
friends) will be set on non-GtkApplicationWindows, such as dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=720550
We don't want the maximum size to be smaller than the minimum size. Not
just because it's wrong but also because when this happens the rest of
GTK gets mighty confused and infloops resizing to min-size and
max-size in turns causing a flickering window. Well, at least if you
run X without a window manager. Or your window manager hasn't finished
starting up.
Private RHEL bug finding this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1035409
Both GtkApplicationWindow and GtkHeaderBar listen for changes
of the gtk-shell-shows-app-menu setting, so they need to somehow
coordinate who is going to take action and show a fallback.
We prefer the menu button in the title over the menubar, so
let GtkApplicationWindow opt out if it finds that the header bar
has been configured to show window controls.
And deprecate the X11-specific version of it.
We call this new API _set_shadow_width() and not _set_frame_extents()
because we already have a gdk_window_get_frame_extents() with a
different meaning and different type of value.
https://bugzilla.gnome.org/show_bug.cgi?id=720374
When setting a custom titlebar that happens to be a GtkHeaderBar,
we connect to notify::title to pick up title changes on the headerbar,
but we forgot to sync the title initially. Fix that.
Win32 does not have alpha channel currently ; fix the check
for this, so trying to enable CSDs on this platform will
not "succeed" and crash the app anymore.
Partially fixes gtk3-widget-factory.
Instead, use the monitor's work area.
This might have unforseen side effects that warrant a later revert, such
as:
- Apparently some WMs assume maximizing when a window is maximum screen
size.
- WMs might not shrink the window by the decorations' size when it tries
to be fullscreen.
- Applications might have buggy size request code that causes weirdly
sized windows.
Do the menubutton for app menu fallback ourselves in GtkWindow
for the csd, non-custom titlebar case. This fits better with
the way we handle other title buttons. Themes have control
over the placement of this button by placing menu in the
decoration-button-layout style property.
Rework how accels are handled on GtkApplicationWindow.
Instead of having GtkApplication fill the GtkAccelMap which is then used
by GtkApplicationWindow to create a GtkAccelGroup filled with closures
that is then associated with the window, do it directly.
GtkApplication now keeps a list of accels and their actions.
Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
appropriate action.
This saves a fair bit of complexity and memory use (due to not having to
create all those closures and accelmap entries). The new approach also
supports multiple accels per action (although there is not yet a public
API for it).
This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
Previously, GtkWindow would add the "app" action group to its own
toplevel muxer.
Change the setup so that GtkApplication creates the toplevel muxer and
adds itself to it as "app". Use this muxer as the parent muxer of any
GtkWindow associated with the application.
This saves a small amount of memory and will allow for accels to be
propagated from the application through to all of the windows.
Resize modes don't work anymore, both because nobody ever uses them and
because the frame clock changed the way things work quite a bit. So we
don't want to advertise them as a good idea.
https://bugzilla.gnome.org/show_bug.cgi?id=708787
Previously, we were showing and hiding the custom titlebar
widget in response to state changes such as maximization.
Instead, use gtk_widget_set_child_visible() and leave
show/hide to applications. This makes it possible to set
a custom titlebar and hide it, for a titlebar-less appearance.
https://bugzilla.gnome.org/show_bug.cgi?id=707132
The size of the shadow and invisible borders can (and usually
will) change between backdrop and focused windows, while the
overall window size remains unchanged. This causes the visible
window to visually 'jump'. We can avoid this by always reserving
the maximum of the focused and unfocused border sizes. The code
for positioning the input-only windows making up the invisible
border is adjusted to deal with this. We now always place the
invisible border right outside the visible content, even if the
shadow extends out much farther.
https://bugzilla.gnome.org/show_bug.cgi?id=707524
We need to subtract border_width from the size we're passing to the
children hfw functions as those are added by ourselves.
Fixes the window-border-width.ui reftest.
At least for header bars, there's often application controls
in this area, which should be included in the focus chain.
We make it so that the initial focus avoids the titlebar,
but tabbing around will eventually get there.
https://bugzilla.gnome.org/show_bug.cgi?id=708067
There were some code added to this file that is meant for the X11 backend,
but they are being unconditionally built. Add build-time checks for the
X11 backend for these to fix the build on non-X11 platforms.
We'll use a style class to be able to give this a different appearance,
but for the time being we don't really need to give this such different
margin.
https://bugzilla.gnome.org/show_bug.cgi?id=706592
"title_box" is used for both a custom header bar and for a titlebar.
Since we want to help differentiate these cases in the code, rename
everything titlebar-internal to use "titlebar_".
https://bugzilla.gnome.org/show_bug.cgi?id=706529
Attached widgets inherit from the style of the widget they are
attached to. This can sometimes have unintended consequences,
like a context menu in the main view of gedit inheriting the font
that is configured for documents, or the context menu of the preview
in the font chooser coming up with humongous font size.
To fix this problem, we introduce a context menu style class
and use it for all menus that are used like that. The theme
can then set a font for this style class.
https://bugzilla.gnome.org/show_bug.cgi?id=697127
Make sure we always deal with the same screen when
connecting / disconnecting the theme-variant changed handler.
Pointed out by Morten Welinder in
https://bugzilla.gnome.org/show_bug.cgi?id=705640
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
