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
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
Just a quick little commit to help clean things up for when we add invisible
borders. Additionally, do a little housekeeping in preview-widget as well.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
There were actually *two* MetaFrameGeometry structs: one in theme-private.h,
one in frame.h. The latter public struct was populated by a mix of (void*)
casting and int pointers, usually pulling directly from the data in the private
struct.
Remove the public struct, replace it with MetaFrameBorders and scrap all
the pointer hacks to populate it, instead relying on both structs being used
in common code.
This commit should be relatively straightforward, and it should not do any
tricky logic at all, just a sophisticated find and replace.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
Add an additional color type to pick up colors defined with
@define-color in the GTK+ theme's CSS:
gtk:custom(name,fallback)
(where "name" refers to the name defined in GTK+'s CSS, and fallback
refers to an alternative color spec which is used when the color
referenced by "name" is not found)
The main intent of the change is to allow designers to improve
Adwaita's dark theme variant without having to compromise on colors
which work in the light variant as well.
https://bugzilla.gnome.org/show_bug.cgi?id=648709
We now use GtkStyleContext exclusively, so it's a bit weird to store
widget state as GtkStateType and translate it always to GtkStateFlags.
Just use GtkStateFlags instead of GtkStateType.
https://bugzilla.gnome.org/show_bug.cgi?id=650586
GtkStyleContext no longer has dark/light colors GtkStyle used to
have. We already have compatibility code for them in theme.c, so
add two helper functions to make it available outside theme.c.
https://bugzilla.gnome.org/show_bug.cgi?id=650586
GdkColor is about to be deprecated, so move to GdkRGBA instead.
It might be worth considering using cairo patterns for the gradients
rather than using custom code to render gradients to a pixbuf which
is then drawn with cairo, but for now this is just a straight port
of the existing code.
https://bugzilla.gnome.org/show_bug.cgi?id=650586
In order to pick up colors from a GtkStyleContext, a temporary
GtkStyle object was created from the context and destroyed after
copying the requested GdkColor. This is slightly inefficient, so
get the appropriate GdkRGBA from the context and translate it to
a GdkColor, based on the compatibility code in gtkstyle.c.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
Rather than using a single widget's style for GTK+ colors in themes,
use the style context parameter of the drawing functions for those
colors. Right now, a single style context is shared between frames,
but this will change to support different style variants.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
If mutter is going to be a "real" library, then it should install its
includes so that users can do
#include <meta/display.h>
rather than
#include <display.h>
So rename the includedir accordingly, move src/include to src/meta,
and fix up all internal references.
There were a handful of header files in src/include that were not
installed; this appears to have been part of a plan to keep core/,
ui/, and compositor/ from looking at each others' private includes,
but that wasn't really working anyway. So move all non-installed
headers back into core/ or ui/.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
GtkStyle has been deprecated in favor of GtkStyleContext. A full
port would involve replacing GdkColor with GdkRGBA - leave this
out for the time being.
Bump the required version of GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=637761
It may be desirable for theme authors to treat side-by-side tiled
windows differently, for instance to give the edge-touching border
a width of 0, so add additional frame states for tiled windows.
https://bugzilla.gnome.org/show_bug.cgi?id=637330
With the existing background functions, single buttons can not be
styled separately - on the left side, the style of the left button
is picked, and the right button's style on the right side.
As theme authors may want to add rounded corners to button groups
as a whole, it makes sense to treat the case of a single button in
a group differently.
https://bugzilla.gnome.org/show_bug.cgi?id=635683
While the configured layout is taken into account for positioning
the buttons, the mapping from button function states to button
position states just assumed the default button layout in LTR
locales.
Do a proper mapping depending on the actual layout instead.
https://bugzilla.gnome.org/show_bug.cgi?id=635686
Frame types will form the bases of shadow classes, which are strings,
so export the to-string function so that we can do the conversion
uniformly.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Add a new frame type META_FRAME_TYPE_ATTACHED which is used for
attached modal dialogs.
The theme format version is bumped to 3.2, and attached windows
can have borders defined in a metacity-theme-3.xml as:
<window version=">= 3.2" type="attached" style_set="[name]"/>
If no style is defined for "attached", drawing will fall back
to the "border" type.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
While the Meego developers agreed to switching mutter to GTK+-3.0
unconditionally a while ago, Canonical used a GTK+-2.0 build for their
Unity project. As Canonical now announced a switch to compiz as their
window manager, there is no longer a reason to maintain GTK+-2.0
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=633133
Remove --allow-unprefixed option to the scanner, and fix resulting
problems:
* theme.h and boxes.h are split into a main -header and a private
header that includes stuff that is not generally useful and
hard to introspect. Merge theme-parser.h into theme.h.
* meta_display_get_atom() and meta_window_get_window_type_atom()
are marked as (skip)
* Fix annotation: (element-type Strut) => (element-type Meta.Strut)
https://bugzilla.gnome.org/show_bug.cgi?id=632494
Simplify the code by noting that when we have square end-caps, the
results of generic line path give the right pixel-aligned rectangle
for horizontal/vertical lines.
Add comments and remove some extra braces.
https://bugzilla.gnome.org/show_bug.cgi?id=630426
Commit aa65f94c67 that started passing
cairo_t around broke offsets. Since passing cairo_t makes them
unnecessary, this patches removes them rather than fixing them.
This patch changes API.
https://bugzilla.gnome.org/show_bug.cgi?id=630203
This commit is in preparation for the work happening in GTK3, which will
use Cairo for drawing exclusively. So it is necessary to move all
drawing code to Cairo. In this commit the "gtk2" code is used for both
gtk2 and gtk3; compatibility with newer versions of gtk3 where different
code is needed will be added subsequently.
For compatibility with older GTK versions, the file gdk2-drawing-utils.h
provides a compatibility layer.
The commit changes the API of libmutter-private.
https://bugzilla.gnome.org/show_bug.cgi?id=630203
Cleanly build with --warn-fatal. Implementation:
* Liberally apply (skip) where the API is clearly C only, e.g. uses
XLib. The theming code and MutterPlugin are skipped too.
* Add missing (transfer) and (element-type) annotations
For a few functions that had a comment, I turned it into gtk-doc, but
I didn't (with a few exceptions) try to write new documentation in
this pass.
To replace all calls to deprecated code, GTK+ 2.20 is required - add
some basic compatibility code, so that it is still possible to build
mutter with GTK+ 2.18 when not using -DGSEAL_ENABLE.
https://bugzilla.gnome.org/show_bug.cgi?id=595496
It's nice to indicate when a title is truncated with an ellipsis.
Because themes may draw a title multiple times to draw a shadow, or
may include the window icon within the title area, we can't determine
the proper ellipsization width automatically, so add an optional
attribute to the <title/> element "ellipsize_width" which, if set,
is the width to ellipsize at.
This is only enabled if a theme version of 3.1 is required.
When it's not set, we keep the old behavior of just letting the
title be clipped with a hard edge.
https://bugzilla.gnome.org/show_bug.cgi?id=591842
Sometimes you want to position something (usually the title) to be centered
with respect to the entire frame instead of centered with respect to the
individual piece currently being drawn.
This patch adds frame_x_center and frame_y_center variables that represent
the X/Y centers of the frame in the coordinate system of the piece being
drawn.
The theme version is bumped from 3.0 to 3.1 (3.0 is just the new version
system, 3.1 will have all the features we add for Mutter-2.28.)
position expressions
https://bugzilla.gnome.org/show_bug.cgi?id=591842
The current mechanism of metacity-theme-1.xml and metacity-theme-2.xml
is not flexible for allowing small-scale additions. With this patch
we bump the major version version once more to metacity-theme-3.xml
and add a single feature:
Any element in the DTD can have an attribute:
version="[<|<=|=>|>] MAJOR.MINOR"
And it will be ignored unless the predicate is met. (< and > should
be to be entity escaped as < and >)
This allows having alternate sections of the theme file for older and
newer version.
* Required GLib version is bumped to 2.14 so we can parse versions
with a regular expression.
* We switch internal version numbers to be "1000 * major + minor"
* We keep a stack of the maximum required version for the current portion
the XML tree so that the "cannot use versions you don't require" stricture
of the old code can be made local to a subpart of the tree.
* A version on the top metacity_theme element causes the entire file to
be ignored; this allows having one metacity-theme-3.xml for version 3.2
and newer (say) and a metacity-1.xml for everything old.
Actual new features will be added starting with 3.1 - 3.0 is just the
version="" feature.
http://bugzilla.gnome.org/show_bug.cgi?id=592503
Lines where x1==x2 or y1==y2 may have the second element null. Lines
where both are null, and the width is zero, are points. This speeds
things up surprisingly much.
svn path=/trunk/; revision=4119
2009-01-27 Owen Taylor <otaylor@redhat.com>
GtkStyle is specific to a particular colormap. Metacity
uses different colormaps for windows with different
visuals, so it must specialize the GtkStyle.
Closes#568365 and #513944.
* src/ui/frames.[ch]: Keep a GtkStyle for each MetaUIFrame, which is
obtained by calling gtk_style_attach() on the style for the
MetaFrames. When the style of the MetaFrames changes, reattach
everything. When we call gtk_style_set_background() pass in the
right style.
* src/ui/themes.[ch]: Create a _with_style() variant of functions that
previously took the style from widget->style passed in, so we
can draw with the right style for the colormap.
svn path=/trunk/; revision=4092
