isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-12 09:16:10 -05:00
Code Issues Packages Projects Releases Wiki Activity

Call GNOME_DOC_INIT() so we can use the gnome-doc-utils variables in our

Browse Source 
2008-10-17  Murray Cumming  <murrayc@murrayc.com>

        * configure.in: Call GNOME_DOC_INIT() so we can use the gnome-doc-utils 
        variables in our Makefile.am:
        * doc/Makefile.am:
        * doc/creating_themes/Makefile.am
        * doc/creating_themes/C/creating_metacity_themes.xml:
        Added this new DocBook document, converted from the HTML here
        http://blogs.gnome.org/metacity/2008/05/30/themes/
        This will be installed for yelp and can be translated and hosted on 
        library.gnome.org.


svn path=/trunk/; revision=3964
This commit is contained in:
Murray Cumming 2008-10-18 01:52:39 +00:00 committed by Thomas James Alexander Thurman
parent 6904b7a5d7
commit 4c3a5883d7
5 changed files with 326 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
ChangeLog
View File

@ -1,3 +1,15 @@
2008-10-17 Murray Cumming <murrayc@murrayc.com>
* configure.in: Call GNOME_DOC_INIT() so we can use the gnome-doc-utils
variables in our Makefile.am:
* doc/Makefile.am:
* doc/creating_themes/Makefile.am
* doc/creating_themes/C/creating_metacity_themes.xml:
Added this new DocBook document, converted from the HTML here
http://blogs.gnome.org/metacity/2008/05/30/themes/
This will be installed for yelp and can be translated and hosted on
library.gnome.org.
2008-10-15 Thomas Thurman <tthurman@gnome.org>
Since Patrick Niklaus's checkin of 2008-08-14 dealt with windows with

6
configure.in
View File

@ -471,15 +471,21 @@ else
GCONF_SCHEMAS_INSTALL_FALSE=
fi
AC_ARG_ENABLE(debug,
[ --enable-debug enable debugging],,
enable_debug=no)
if test "x$enable_debug" = "xyes"; then
CFLAGS="$CFLAGS -g -O -Wall"
fi
# Use gnome-doc-utils:
GNOME_DOC_INIT([0.9.0])
AC_CONFIG_FILES([
Makefile
doc/Makefile
doc/creating_themes/Makefile
doc/man/Makefile
src/Makefile
src/wm-tester/Makefile

2
doc/Makefile.am
View File

@ -1,4 +1,4 @@
SUBDIRS = man
SUBDIRS = man creating_themes
EXTRA_DIST=theme-format.txt metacity-theme.dtd dialogs.txt code-overview.txt \
how-to-get-focus-right.txt

283
doc/creating_themes/C/creating_metacity_themes.xml Normal file
View File

@ -0,0 +1,283 @@
<?xml version="1.0"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://docbook.org/docbook/xml/4.5/docbookx.dtd" [
]>
<book>
<bookinfo>
<title>Understanding Metacity Themes</title>
<authorgroup>
<author>
<firstname>Thomas</firstname>
<surname>Thurman</surname>
</author>
</authorgroup>
<abstract>
<para>
We very much appreciate any reports of inaccuracies or other errors in
this document. Contributions are also most welcome. Post your
suggestions, critiques or addenda to the <ulink
url="mailto:tthurman@gnome.org">team</ulink>.</para>
</abstract>
<copyright>
<year>2008</year>
<holder>Thomas Thurman</holder>
</copyright>
<legalnotice>
<para>
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
You may obtain a copy of the GNU Free Documentation License from the Free Software Foundation by visiting their Web site or by writing to: Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
</para>
</legalnotice>
</bookinfo>
<chapter id="sec-introduction">
<title>Introduction</title>
<para>This is an article about how to theme Metacity. It is a work in progress, and I have had to dig deeply to find some answers; I may well have made mistakes and I welcome corrections and suggestions.</para>
<para>GNOME lets you theme a bunch of different things, but we're only talking about <literal>window border</literal> themes here, which some people call Metacity themes; <link url="http://en.wikipedia.org/wiki/Metacity#Themes">Wikipedia begins a sentence</link> with &quot;Despite the incomplete state of Metacity theme development documentation&quot;, and though there <emphasis>is</emphasis> <link url="http://svn.gnome.org/viewvc/metacity/trunk/doc/theme-format.txt?view=markup">documentation in the source</link>, apparently not many people find it, and it's written more for programmers than theme designers. Glynn Foster also wrote <link url="http://developer.gnome.org/doc/tutorials/metacity/metacity-themes.html">a very good introduction to Metacity themes</link> <sup><link url="http://home.arcor.de/rybaczyk/documents/tutorials/metacity/metacity-themes.de.html" hreflang="de">[de]</link></sup> six years ago, but things have changed a little since then. <link url="http://lists.freedesktop.org/archives/compiz/2006-September/000445.html">Metacity themes can also be used by Compiz</link>, and perhaps by other window managers for all I know.</para>
<para>So, a Metacity theme is a set of instructions about how to &quot;decorate&quot; (draw the borders around) a window. Presumably you don't want to style all windows identically, so the format lets you specify details for different kinds of window:</para>
<para>
<variablelist>
<varlistentry>
<term>state:</term><listitem><para>Every window must be in exactly one of these states: <literal>normal</literal>, <literal>dialog</literal>, <literal>modal dialog</literal> (i.e. a dialogue which means you can't interact with the rest of the program while it's up), <literal>menu</literal> (torn off from the main application, not that people do that much these days), <literal>utility</literal> (that is, palettes and toolboxes and things), and <literal>border</literal>. X also allows a window to explicitly ask to be undecorated, but of course we don't provide for those in a list of decoration instructions.</para></listitem>
</varlistentry>
<varlistentry>
<term>focused</term><listitem><para>Every window is either the active window (which X people call &quot;focused&quot;), or it isn't.</para></listitem>
</varlistentry>
<varlistentry>
<term>maximized</term><listitem><para>Every window is either (fully) maximised (horizontal and vertical only don't count), or it isn't.</para></listitem>
</varlistentry>
<varlistentry>
<term>shaded</term><listitem><para>Every window is either rolled up to show just its titlebar (which techies call &quot;shaded&quot; for some reason I can't fathom), or it isn't.</para></listitem>
</varlistentry>
</variablelist>
</para>
<para>
<itemizedlist>
<listitem><para><emphasis>If a window is not fully maximised and not shaded,</emphasis> it either allows horizontal resizing, or it doesn't.</para></listitem>
<listitem><para><emphasis>If a window is not fully maximised and not shaded,</emphasis> it either allows vertical resizing, or it doesn't.</para></listitem>
</itemizedlist>
</para>
</chapter>
<chapter>
<title>What's in the file</title>
<para>The files must be called either</para>
<para>
<itemizedlist>
<listitem><para>~/.themes/<varname>N</varname>/metacity-1/metacity-theme-<varname>V</varname>.xml
for a theme used only by you, or</para></listitem>
<listitem><para>/usr/share/themes/<varname>N</varname>/metacity-1/metacity-theme-<varname>V</varname>.xml
for a theme installed for all users.</para></listitem>
</itemizedlist>
</para>
<para>where <varname>N</varname> is the name of the theme and <varname>V</varname> is the version of the format. Version 2, <link url="http://svn.gnome.org/viewvc/metacity?view=revision&amp;revision=2973">introduced in October 2006</link>, adds a few extra features, but it's rarely used. Version 1 is the original format. The formats are fixed once they're stable for both backwards and forwards compatibility; <link url="http://bugzilla.gnome.org/show_bug.cgi?id=482165">new features</link> can't be added without introducing a new version number, which is why improvements come out rarely and in large clumps. <literal>metacity-1</literal> in the names is a fossil and doesn't mean version 1 of anything.</para>
<para>The metacity-theme-V.xml files are <link url="http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/">GMarkup files</link>, which are very similar to XML. For now, you actually have to write these in a text editor or something; you can either start with a blank page, or modify a theme someone else has made. (I am thinking of writing a general theme editor program, but that'll have to wait until I've reduced Metacity's open bug queue a little.) If you want to see a fully-fledged one, you can look at <link url="http://svn.gnome.org/viewvc/metacity/trunk/src/themes/Atlanta/metacity-theme-1.xml?view=markup">the current version of &quot;Atlanta&quot;</link>, one of the simplest themes, but even that is quite complicated-looking at first.</para>
<para>So, let's talk about what actually goes inside the files. As in any XML file, &lt;!-<!-- x -->- &#8230; <!-- x -->&gt; are comments. At its most basic, it would go:</para>
<para>
<programlisting>
&lt;metacity_theme&gt;
&lt;!-<!-- x -->- Helper stuff: -<!-- x -->-&gt;
&lt;info &#8230;&gt; &lt;!-<!-- x -->- to be explained -<!-- x -->-&gt;
&lt;constant &#8230;&gt; &lt;!-<!-- x -->- maybe; to be explained -<!-- x -->-&gt;
&lt;draw_ops &#8230;&gt; &lt;!-<!-- x -->- maybe; to be explained -<!-- x -->-&gt;
&lt;!-<!-- x -->- Things we build the top level onto: -<!-- x -->-&gt;
&lt;frame_geometry &#8230;&gt; &lt;!-<!-- x -->- to be explained -<!-- x -->-&gt;
&lt;frame_style &#8230;&gt; &lt;!-<!-- x -->- to be explained -<!-- x -->-&gt;
&lt;frame_style_set &#8230;&gt; &lt;!-<!-- x -->- to be explained -<!-- x -->-&gt;
&lt;!-<!-- x -->- And the top level: -<!-- x -->-&gt;
&lt;window type=&quot;normal&quot; style_set=&quot;&#8230;&quot; /&gt;
&lt;window type=&quot;dialog&quot; style_set=&quot;&#8230;&quot; /&gt;
&lt;window type=&quot;modal_dialog&quot; style_set=&quot;&#8230;&quot; /&gt;
&lt;window type=&quot;menu&quot; style_set=&quot;&#8230;&quot; /&gt;
&lt;window type=&quot;utility&quot; style_set=&quot;&#8230;&quot; /&gt;
&lt;window type=&quot;border&quot; style_set=&quot;&#8230;&quot; /&gt;
&lt;/metacity_theme&gt;
</programlisting>
</para>
</chapter>
<chapter>
<title>Matching windows</title>
<para>
<variablelist>
<varlistentry>
<term>window</term><listitem><para>You see that at the top level we have a list of &lt;window&gt; tags, one for each window state we discussed above. The style_set argument of each of these gives the name of a frame_style_set.</para></listitem>
</varlistentry>
<varlistentry>
<term>frame_style_set:</term><listitem><para>tells Metacity how to draw windows according to whether they're focused or not, maximised or not, shaded or not, and allowing resizing vertically, horizontally, both, or neither. It looks like this:</para></listitem>
</varlistentry>
</variablelist>
<para>
<programlisting>
&lt;frame_style_set&gt;
&lt;frame focus=&quot;F&quot; state=&quot;S&quot; resize=&quot;R&quot; style=&quot;N&quot;/&gt;
&lt;frame&#8230; /&gt;
&#8230;
&lt;/frame_style_set&gt;
</programlisting>
</para>
<para>where:</para>
<para>
<variablelist>
<varlistentry>
<term>F</term><listitem><para>is yes for focused, no for unfocused.</para></listitem>
</varlistentry>
<varlistentry>
<term>S</term><listitem><para>combines the shaded and maximized flags: normal, maximized, shaded, or maximized_and_shaded.</para></listitem>
</varlistentry>
<varlistentry>
<term>R</term><listitem><para>represents resize permissions that the window gives us: none, vertical, horizontal, or both. Frame settings for maximised windows, which can't be resized, don't have this attribute.</para></listitem>
</varlistentry>
</variablelist>
</para>
<varname>N</varname> is the name of a <literal>frame_style</literal> to apply to a window which has these attributes.</para>
<para>A <literal>frame_style_set</literal> tag may also have a &quot;parent&quot; tag, which should be the name of another <literal>frame_style_set</literal>. This means that if Metacity wants to know about a kind of window which that <literal>frame_style_set</literal> doesn't describe, it should look in the parent. Most of the more complicated tags in Metacity theme files also have a &quot;parent&quot; attribute which work the same way. This is particularly useful because, taken together, all the <literal>frame_style_set</literal>s in a theme file must be capable of matching every possible kind of window; if a window turns up that they can't match, there will be an error at runtime.</para>
<para>Let's recap what we've seen so far. The combination of a <literal>window</literal>, which matches a window's state (normal, dialog, and so forth), with an entry in the corresponding <literal>frame_style_set</literal>, which matches its focus, shadedness, maximisedness, and resize permissions where relevant, will allow you to make a list of rules to match any window against. The next piece of this puzzle lets you specify what Metacity should do with such windows once it's matched them.</para>
</chapter>
<chapter>
<title>Actually drawing stuff</title>
<para><literal>frame_style:</literal> This is probably the most complicated part of the whole system. A <literal>frame_style</literal> a series of <emphasis><literal>piece</literal></emphasis>s and <emphasis><literal>button</literal></emphasis>s. It looks like this:</para>
<para>
<programlisting>
&lt;frame_style name=&quot;&#8230;&quot; geometry=&quot;G&quot;&gt;
&lt;piece position=&quot;P&quot;&gt;
&lt;draw_ops&gt;
&lt;/draw_ops&gt;
&lt;/piece&gt;
&#8230;
&lt;button function=&quot;F&quot; state=&quot;S&quot; draw_ops=&quot;D&quot;/&gt;
&lt;draw_ops&gt;
&lt;/draw_ops&gt;
&lt;/button&gt;
&#8230;
&lt;/frame_style&gt;
</programlisting>
</para>
<para>The <literal>pieces</literal> are pieces of the window frame. When Metacity draws a window frame, it renders its various pieces always in the same order. The bolded parts are all the possible values of P:</para>
<para>
<itemizedlist>
<listitem><para>the <literal>entire_background</literal>, covering the whole frame</para></listitem>
<listitem><para>the <literal>titlebar</literal>, covering the entire background of the titlebar</para></listitem>
<listitem><para>the <literal>titlebar_middle</literal>, the part of the titlebar that doesn't touch its edges</para></listitem>
<listitem><para>the <literal>left_titlebar_edge</literal>, <literal>right_titlebar_edge</literal>, <literal>top_titlebar_edge</literal>, and <literal>bottom_titlebar_edge</literal></para></listitem>
<listitem><para>the <literal>title</literal>, just exactly that area which is covered by the text on the titlebar</para></listitem>
<listitem><para>the <literal>left_edge</literal>, <literal>right_edge</literal>, and <literal>bottom_edge</literal> of the frame (yes, there is no top_edge: it's identical to top_titlebar_edge, isn't it?)</para></listitem>
<listitem><para>the <literal>overlay</literal>, which covers everything&#8211; the same as entire_background, but done last instead of first.</para></listitem>
</itemizedlist>
</para>
<para><emphasis>What</emphasis> Metacity draws in these pieces is decided by the theme. If a <literal>frame_style</literal> or its parents don't specify a particular piece, nothing will be drawn for that piece. You have two ways to specify what to draw: one is that the <literal>piece</literal> tag can have a <literal>draw_ops</literal> tag inside it which lists a sequence of drawing operations in Metacity's custom format. <link url="http://bugzilla.gnome.org/show_bug.cgi?id=107012">You might ask why we don't use SVG</link>; one answer is that SVG support wasn't very strong when this format was designed, and another answer is that these days you can use SVG all you like; just include it as an image and Metacity will know what to do.</para>
<para>An alternative to including a draw_ops tag inside a piece tag is to add a draw_ops attribute to the piece tag. Then you can add a draw_ops tag at top level (inside the metacity_theme tag) with a name attribute, and Metacity will use that. This is useful if you use similar draw_ops over and over.</para>
<para>I'm not going to document draw_ops at present, because this is already very long. I will write it up later and link it from here.</para>
<para>The <literal>button</literal> tag tells Metacity how, but not where, to draw buttons. Buttons are drawn after all the pieces are finished, and the way to draw them is also given using draw_ops. You ought to provide buttons for all the possible kinds of button; if you don't give one it won't be drawn, which is unfortunate for the user who wants to use it:</para>
<para>
<itemizedlist>
<listitem><para><literal>left_left_background</literal>, <literal>left_middle_background</literal>, and <literal>left_right_background</literal> don't represent buttons as such, but the background behind them, assuming there can be at most three buttons on the left. These days there can be more, so the extra ones also use left_middle_background.</para></listitem>
<listitem><para><literal>right_left_background</literal>, <literal>right_middle_background</literal>, and <literal>right_right_background</literal> similarly.</para></listitem>
<listitem><para><literal>close</literal>, <literal>minimize</literal>, <literal>maximize</literal> are the obvious original three buttons.</para></listitem>
<listitem><para><literal>menu</literal> is the menu button you can click to get a list of actions you can perform on the window.</para></listitem>
<listitem><para><literal>shade</literal>, <literal>above</literal>, <literal>stick</literal> are similar to the original buttons but only allowed in version 2</para></listitem>
<listitem><para><literal>unshade</literal>, <literal>unabove</literal>, <literal>unstick</literal> are the toggled versions of these buttons. Again, version 2 only. <strike>It is not immediately apparent to me how the toggled version of <literal>maximize</literal> is generated, though I suppose I must have known at some point.</strike></para></listitem>
</itemizedlist>
</para>
<para>The reason there are toggled versions of shade, above, and stick, and not maximize, is that by the time you get this far you've probably already decided whether you're drawing a maximised window. So if you <emphasis>are</emphasis> drawing a maximised window, you can make the button called &quot;maximize&quot; look how you want the restore button to be; otherwise, make it look like you want the maximise button to be.</para>
<para>For each button tag you should also set a &quot;state&quot; attribute; this time the state is either <literal>normal</literal> (the way you see it most of the time), <literal>pressed</literal>, or <literal>prelight</literal> (this makes the buttons subtly light up when you hover over them). You only really need &quot;normal&quot;, but the others are good to have too.</para>
<para>The &quot;geometry&quot; attribute of a <literal>frame_style</literal> tag is the name of a&#8230;</para>
</chapter>
<chapter>
<title>Geometry</title>
<para>The <literal>geometry</literal> tag defines the sizes of things around the window. It is important, but not easy to explain, and again this file has gone on too long. I'll write it up later.</para>
</chapter>
<chapter>
<title>Other things which lie around a file</title>
<para>The most important other thing in a theme file is the metadata held in the <literal>info</literal> tag. This contains a set of tags each of which contains some text explaining something about the theme itself, in a sort of <link url="http://en.wikipedia.org/wiki/Dublin_Core">Dublin Core</link> sort of way. (Next time around, we should probably use the actual Dublin Core.) The tags are <literal>name</literal>, <literal>author</literal>, <literal>copyright</literal>, <literal>date</literal>, and <literal>description</literal>.</para>
<para>Version 1 of the format had a <literal>menu_icon</literal> tag at top level, which let themes specify the icons beside options in the menu you get from the menu icon. This has become redundant; the icons are taken from the icon theme! The tag can still be used in all formats, but does nothing and is deprecated.</para>
<para>Version 2 of the format has a <literal>fallback</literal> tag at top level, which let the theme specify what icon a window should be considered to have if it doesn't provide an icon of its own. This should also be taken from the icon theme, <link url="http://bugzilla.gnome.org/show_bug.cgi?id=524343">if anyone fancies fixing it</link>, and the tag should also then be deprecated. It shouldn't be hard.</para>
</chapter>
<chapter>
<title>When you're working on a theme</title>
<para>When you're editing a theme, you can view it without using it on the whole desktop using
<command>metacity-theme-viewer <emphasis>YourThemeName</emphasis></command></para>
<para>and view it on the whole desktop using
<command>gconftool -<!-- x -->-type=string -<!-- x -->-set /apps/metacity/general/theme <emphasis>YourThemeName</emphasis></command></para>
<para>Whenever you change the selected theme in GConf, Metacity will load the newly-chosen theme. This is how control-center does it. But when you change a theme, as you're working on it, you might want to ask Metacity to reload the theme which is currently used on the whole desktop to reflect your changes. You can do this using the little-known <command>metacity-message</command> program, with the command <literal>metacity-message reload-theme</literal>. This works by sending the ClientMessage <literal>_METACITY_RELOAD_THEME_MESSAGE</literal> to the root window, in case you're interested.</para>
<para>Once you're done with your theme, consider submitting it to <link url="http://art.gnome.org/themes/metacity/">the art.gnome.org site</link>, or <link url="http://www.gnome-look.org/index.php?xcontentmode=101">the gnome-look site</link>.</para>
</chapter>
<chapter>
<title>The future</title>
<para>Please feel free to link to this so people don't have to keep asking the basic questions and can start asking the deeper ones. One of the important deeper ones is: where should we go in the future? Since this format is becoming something of a de facto standard between window managers, should we set up some kind of freedesktop.org standards discussion? Would it be useful to spin off Metacity's theme parsing code into a separate, LGPL-licensed library so that other applications could use it more easily?</para>
<para>What would a version 3 of this format look like? Could we simplify the window / frame_style_set system? (I can imagine abolishing both, and being able to write <literal>&lt;frame_style for=&quot;normal+unfocused+maximized&quot;&gt;&#8230;</literal> and having Metacity assume it applied to all resize permissions and shadednesses.) Maybe we should try to do everything with SVG we can? Getting more wild and handwavey, is it worth keeping XML-like? Maybe if other window managers were dealing with the files, .ini-style files would be more universally useful? Or perhaps not. And then of course we need a decent graphical editor for it. I have a few ideas, but if anyone fancies jumping in...</para>
</chapter>
</book>

24
doc/creating_themes/Makefile.am Normal file
View File

@ -0,0 +1,24 @@
### This part of Makefile.am can be customized by you.
# gnome-doc-utils standard variables:
include $(top_srcdir)/gnome-doc-utils.make
dist-hook: doc-dist-hook
# The name of the directory in /usr/share/gnome/help/,
# and the name of the main .xml file:
DOC_MODULE = creating_metacity_themes
# The names of any files included via entity declarations.
DOC_ENTITIES =
# The names of any files included by xincluded (preferred):
DOC_INCLUDES =
# The names of any pictures:
DOC_FIGURES =
# The names of any locales for which documentation translations exist:
DOC_LINGUAS =