Rename the "toggled" property to "active", since that is what
GtkActionHelper expects to update for check and radio actions.
Also make the property readable, since GtkActionHelper wants
to read it.
The visuals are typically sorted by some sort of "most useful first"
order. And picking the last one is likely to give us the weirdest
matching glx visual.
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.
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
