The differences between the mutter and GTK+ code are subtle, but it
turns out that _gtk_cairo_blur_compute_pixels actually returns the
shadow *spread*. Since we use a triple box blur, the constant was
multiplied by 1.5 to approximate three chained box blurs. Split this
out and use the correct value for the lobe width.
We weren't passing in the right "d" value, which was causing the blur to
behave incorrectly, especially in the case of 1px blurs, which would
cause no blurs at all.
The blur should now match the web.
We don't want separators in both side of an iconic section
and use a 10px margin to separate two iconic sections.
Separators are also updated in case of dynamic insertion
( often used with menu items for plugins )
https://bugzilla.gnome.org/show_bug.cgi?id=738650
We want to be able to style the empty blocks independently of all the
offset styles, so remove the current style class when painting an empty
block.
https://bugzilla.gnome.org/show_bug.cgi?id=707695
It is not possible to successfully build GTK+ on OS X 10.6 and below
since NSFullScreenWindowMask is only available starting with 10.7. Add
ifdef guards around setStyleMask: in order to allow it to build on
earlier OS X releases.
https://bugzilla.gnome.org/show_bug.cgi?id=737561
Commit 30a1c4ab fixed several memleaks including one in
gtk_font_chooser_widget_find_font.
However, the fix causes one extra call to gtk_tree_model_iter_next()
after finding the font we look for (ie pango_font_description_equal
returns TRUE): the 'increment' part of the for loop
(gtk_tree_model_iter_next) is run before the 'exit condition' of the for
loop is evaluated.
This commit reverts this part of commit 30a1c4ab and adds an extra
call to pango_font_description_free in order to fix the leak.
https://bugzilla.gnome.org/show_bug.cgi?id=739111
When using GtkFontChooserButton, the same GtkFontChooserWidget can be
hidden and shown multiple times. When doing that, the font that was
chosen the previous time should be the selected one in the
GtkFontChooserWidget, however this does not work as expected and a
somehow 'random' font gets selected (or none) instead.
Every time the font chooser widget is shown, its style will be updated,
causing gtk_font_chooser_widget_style_updated and then
gtk_font_chooser_widget_load_fonts to be called.
gtk_font_chooser_widget_load_fonts starts by clearing the GtkListStore
listing the available fonts, repopulates it, and then makes sure the
current font is selected.
However, this does not work as expected, as during the call to
gtk_list_store_clear, the cursor_changed_cb will be invoked multiple
times when the GtkTreeView cursor gets moved when the line where the
cursor currently is gets removed. This will cause the 'current font'
state (priv->font_desc) to be unexpectedly modified, and when
gtk_font_chooser_widget_load_fonts tries to reposition the cursor to the
'current font', we won't get the expect result.
This commit avoids that by making sure cursor_changed_cb does not get
called when we call gtk_list_store_clear in
gtk_font_chooser_widget_load_fonts.
https://bugzilla.gnome.org/show_bug.cgi?id=739111
Commits 314b6abbe8 and eb9223c008 were ignoring
the fact that the code where found is set to 1 was modifying
col - which was an ok thing to do when that part of the code
was still breaking out of the loop, but it is no longer doing
that (since 2003 !). Fix things up by storing the final col
value in a separate variable and using that after the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=738886
Failure to do so results in custom styling leaking through in
the inspector. This is pretty obvious, now that the inspector
is using a separate display connection and is generally isolated
from style changes.
In various places, the broadway backend was just using
the default display and assumed that it is the broadway
display. That may not be the case in a multi-backend world,
so instead iterate over all displays and use the first
broadway display - still not perfect, but enough to survive
for now.
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.
GtkStyleContext was not properly handling the style cascade when
setting a screen, causing the inspector global CSS to affect the
inspector window, even though the inspector is using a different
screen now.
This helps isolate the inspector from some of the changes that
it can trigger. To specify a different display, set
GTK_INSPECTOR_DISPLAY to the name of the display to use for
the inspector window. If no display is specified, GTK+ will
use a separate connection to the default display.
