The style context of the widget is rarely what we want. We won't
fix this to be a MetaFrames style context yet; this just changes
the internal API.
https://bugzilla.gnome.org/show_bug.cgi?id=690317
This removes our final dependency on Core Events, meaning
we can remove support code for them soon.
This commit is a bit ugly as it requires ui having a dependency on
core, but this is already a hack, so this is thus a hack inside a
hack, and two hacks make a right or however that goes.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
Since GTK+ commit b1ad5c8abc2c, GtkSetting's CSS provider uses a
priority of GTK_STYLE_PROVIDER_PRIORITY_SETTINGS, which means it
will overwrite the ones we create ourselves.
Bump the priority to fix dark window decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=688182
The concept of a clip region doesn't make sense now that we have anti-aliased
corners and a full alpha channel. Once the theme transition is complete,
creating a preview image with an alpha channel will be possible by passing
an ARGB surface to gtk_widget_draw(preview_widget, ...);
https://bugzilla.gnome.org/show_bug.cgi?id=676052
Since we now cache windows in the X server, we don't really need to cache
them here. Since we are redirecting windows in most cases, we're not gaining
anything except added memory usage. Additionally, remove the clip to screen
optimization - if a window is partially off-screen, we still need to draw
the entire thing as redirection means we won't get an expose event for it.
Additionally, when introducing invisible borders, something accidentally
slipped through: we were getting expose events on the invisible borders,
and they weren't in the cached pixels rect, so we were painting the theme
for them, even if we didn't actually paint anything with cairo. Make sure
to clip out the invisible borders instead of just the client rect so that
we don't draw if our expose event is on the invisible borders.
https://bugzilla.gnome.org/show_bug.cgi?id=675111
It seems that the only usage of the "widget" parameter throughout
the entire call chain was to pass between two function calls as
mutual recursion.
https://bugzilla.gnome.org/show_bug.cgi?id=671104
After the changes in style handling in GTK+, mutter's tooltips no
longer match the tooltip style used in applications. Given that
all buttons in the default layout are well-known, killing tooltips
altogether rather than fixing the styling issues looks like a valid
approach.
https://bugzilla.gnome.org/show_bug.cgi?id=645101
We were relying on GTK+ emitting GtkWidget::style-updated during
widget initialization to create the GtkStyleContexts used for
window decorations. A recent GTK+ update broke this assumption,
so do the necessary initialization ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=671796
Move preferences to GSettings, using mainly shared schemas from
gsettings-desktop-schemas.
Unlike GConf, GSettings support is not optional, as Gio is already
a hard dependency of GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=635378
The theme state used to use GtkStateType, but was ported over to GtkStateFlags,
leaving behind a broken assertion that fails when using certain Metacity
themes, for example Nodoka.
https://bugzilla.gnome.org/show_bug.cgi?id=661286
Shaded windows are assumed to be reduced to the titlebar: the
current code enforces a visible bottom border of 0 and only takes
the size of the title bar (+ invisible top border) into account
when resizing the frame. However, we still add an invisible border
at the bottom, which is than subtracted from the title bar, resulting
in shaded windows being cut off.
Fix by forcing both visible and invisible bottom borders to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=659266
If we do this, then there will be invisible borders around the top of attached
modal dialogs, which is unnecessary -- they can't be resized from the top
border and just interfere with the parent dialog.
This requires changing a bit of API to help identify the type of dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=657795
gtk:custom() requires a fallback color in case the GTK+ theme in use
does not define the desired color. As in general the fallback color
will approximate the intended color, there is the risk of typos going
unnoticed. To make catching these kind of errors easier, allow to ignore
the fallback color specified (and fall back to a nice shade of pink
instead) by setting an environment variable.
https://bugzilla.gnome.org/show_bug.cgi?id=656112
