This ensures that widgets that aren't ported and rely on the style-set
signal being emitted work as well as before. They should not rely on
style-set being emitted however.
Note that this function is a no-op if the initial style has been set
already and is very cheap if it has not been set yet. It only becomes
relevant if the resulting style actually gets used.
https://bugzilla.gnome.org/show_bug.cgi?id=639584
The intention of this patch is to make the code clearer, shorter and
most of all to avoid recreating the widget path and setting it path
twice on the style context when the style context was recreated.
Now that we have wesome macros in glib 2.0, we can use them. Woohoo, GTK
2.0 will be so awesome in the future.
(Did anybody touch dnd code this millenium?)
gtk_settings_get_default() was used to monitor the
"gtk-application-prefers-dark-theme" setting, rather
than the GtkSettings object associated with the window's
screen.
The metacity theme format allows to use colors from the current
GTK+ theme in window decorations. Since GTK+ now gained support
for dark theme variants, window managers using that theme format
(metacity, mutter, compiz via gtk-window-decorator) should be able
to use colors from the correct variant; so in case a variant is
requested, export it in the _GTK_THEME_VARIANT property on
toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645354
You can select something, but moving the focus somewhere else, or bringing up
the context menu makes the selection go away. This makes it impossible to
copy-paste the text.
The reason for this regression is that gtk_label_state_changed was sloppy and
assumed that it would only ever be called when a labels goes insensitive, which
is no longer the case.
The patch fixes things by explicitly checking if the widget is insensitive, and
only resetting the selection in that case, which is the same behaviour we have
for e.g. GtkEntry.
It turns out the bug is more complicated than I originally understood.
Not replacing the font description fields while merging here makes it
impossible for application's CSS to override fonts.
This reverts commit 89c1d93b68.
https://bugzilla.gnome.org/show_bug.cgi?id=645458
Use the background color instead.
I think the optimal solution would be delegating the shadow rendering to
the theme completely, and removing this in GtkThemingEngine, but for
now, this simple fix makes the dark variant more usable.
https://bugzilla.gnome.org/show_bug.cgi?id=645405
