Since Wayland is using libxkbcommon, it inherits X unfortunate
real/virtual modifier distinction, so we have to do the same
gymnastics we do for X to map between the two.
This should fix matching of accelerators using virtual modifiers
(modulo gnome-shell bugs regarding the handling of Super).
https://bugzilla.gnome.org/show_bug.cgi?id=764424
glade-previewer places a gtkwindow inside another toplevel gtkwindow,
updating the shadow width for the client induces a busy loop where the
parent will grow continuously until it crashes gnome-shell/mutter.
To avoid the loop, do not update the shadow width if not dealing with a
toplevel window.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761651
A naive way to perform an action on all parent nodes of a given node
could be to do:
while(gtk_tree_model_iter_parent(model, &iter, &iter)) {
/* perform some action on iter here */
}
However, since gtk_tree_model_iter_parent() will initialize the iterator
pointed to by the second parameter before performing the lookup, this
will not work.
Explicitly document this behaviour.
Signed-off-by: Wouter Verhelst <w@uter.be>
https://bugzilla.gnome.org/show_bug.cgi?id=573380
The previous patches didn't mark some strings as to be translated, and
tried to translate strings with a variable part already inside the
string, which isn't going to work.
Mark the strings as translatable with context, and also make sure to
translate static strings when getting them out of their structure.
https://bugzilla.gnome.org/show_bug.cgi?id=764585
broken from my previous commit about rounded corners, dialogs
doesn't use the "window" node, but the "dialog" node, so use the
.background styleclass in the selectors which is more generic.
When clearing the icon helper, we need to invalidate it. Otherwise the
previous icon keeps lingering along.
This is not relevant inside gtkiconhelper.c where other code causes the
invalidation, but happens when external code calls
_gtk_icon_helper_clear().
https://bugzilla.gnome.org/show_bug.cgi?id=765066
This makes usage of _gdk_display again when creating a window.
This is needed because there is a window created when the display
is being initialized, so it becomes a chicken and egg problem.
For now we roll back this to fix the wintab crash but we might
want to fix this again in the future by improving the wintab
initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=764664
The zoom/rotate change for quartz does not build on 10.7. This change
adds zoom/rotate support in quartz only for 10.8 and following. The
problems is described here:
https://bugzilla.gnome.org/show_bug.cgi?id=760276 and here
https://trac.macports.org/ticket/51052
NSEventPhaseMayBegin was only introduced in 10.8 although documentation
says it is introduced in 10.7. Tests on 10.7 indicate that the phase
property for the Magnify event is not supported at all on 10.7
This fixes a bug that was introduced by db1b24233e.
The reason why 0:0 coordinates were passed was that SWP_NOREPOSITION was
misinterpreted as SWP_NOMOVE. That is not the case - SWP_NOREPOSITION
prevents owner Z-order change, not the window position change.
gnome-control-center is calling gtk_window_resize() on configure-event
signals which leads to a busy loop.
Avoids such a busy loop by not re-configuring a window with the same
size, unless this is coming from and xdg-shell configure.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764374
This commit was found to make emacs windows shrink, but the reversal
caused more widespread damage than initially expected. I've send
suggested fixes to the emacs team, to avoid the shrinking window,
regardless of this commit.
Original commit message:
It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().
If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.
