The test case uses a weak ref to assert objects can finalize,
and then spins the main loop shortly after finalizing to assert
that the finalized object did not leak GSources into the main context
causing latent crashes.
When the window has no mnemonics modifier set, as in the case of a
GtkMenu, never schedule a display of mnemonics on focus-in.
Previously, for those windows, the GdkModifierType mask fetched from the
device would typically have been zero, leading to the
mnemonic_modifier == (mask & gtk_accelerator_get_default_mod_mask ())
check to succeed, so we would always trigger a display for popup menus.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
Don't mention "auto mnemonics", since those methods are purely about
scheduling a delayed display, and that makes understanding the code a
bit harder.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
Some functions in gtkstyle.h were overlooked when we added the
GDK_DEPRECATED macros.
Also add IGNORE_DEPRECATIONS to the few remaining callers of those
functions.
First of all, that call is deprecated. Second, we don't have RC styles
anymore. Third, what that function does today is invalidate style
contexts, but that happens automatically when setting the screen on the
style context later.
So this function is completely unnecessary.
Don't just create a menushell and populate it with random data -- verify that
the resulting menu layout is actually correct.
This is introduced in a separate commit because the old code was failing this
part of the test.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
GtkMenuTracker folds a nested structure of sections in a GMenuModel into
a single linear menu, which it expresses to its user by means of 'insert
item at position' and 'remove item at position' callbacks.
The logic for where to insert separators and how to handle action
namespaces is contained within the tracker, removing the need to have
this logic duplicated in the 3 or 4 places that consume GMenuModel.
In comparison with the previous code, the tracker no longer completely
destroys and rebuilds menus every time a single change occurs. As a
result, the new gtkmenu testcase now runs in approximately 3 seconds
instead of ~60 before.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
The following CSS would infloop:
@define-color self @self
as it would infinitely lookup the color named "self" and try to resolve
it. This patch adds detection of such cycles to the resolve function by
keeping a list of currently resolving colors in the cycle_list variable.
If a named color references a nonexistant named color, we didn't catch
that error and ended up crashing on a NULL-dereference.
This crashed Boxes, because its CSS referenced values from the theme
that didn't exist in any theme.
We were calling gtk_overlay_child_allocate() both in realize
and in add as we wanted to create and position the child windows
for the widgets. However, this call also actually called
gtk_widget_size_allocate() on the child, which it shouldn't. In some
cases the overlay is realized before being allocated, and thus it
will allocate the child at 0x0 which is an invalid size for it to be in.
In particular, if the child has margins set this will result in negative
allocations and warnings.
This fix splits out the allocation computation so that
gtk_overlay_create_child_window can use it without callers
having to call gtk_overlay_child_allocate() to move the windows.
https://bugzilla.gnome.org/show_bug.cgi?id=696623
When no GDK backend can be initialized (either because
GDK_BACKEND has been set to the wrong value, or the backends
are simply not included), the expectation is that gtk_init_check
should return FALSE, not error out.
This commit makes it so, by using gdk_display_manager_peek
instead of gdk_display_manager_get in code paths that are used
during initialization.
This is an (unintentional) side effect of my changes to GtkTreeView's
get_preferred_size() implementation. It seems odd to me that
GtkTreeView directly determines its own size when inside a
GtkScrolledWindow, but since it does, it should be using its natural
size, not its minimum size.
This make the nice 'snap off' feature of gnome-shell work
with client-side decorations. weston moves the maximized window
around, which is less ideal...
We already set it in init, so this is just redundant.
The additional window-content style class here is needed so that we can
distinguish between the full X window background and the background for
the actual window contents.
