metacity-common 1:3.14.3-1 / usr / share / help / de / creating-metacity-themes / index.docbook

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://docbook.org/docbook/xml/4.5/docbookx.dtd">
<book id="index" lang="de">

  <bookinfo>

    <title>Metacity-Themen im Detail</title>

    <authorgroup>
      <author>
        <firstname>Thomas</firstname>
        <surname>Thurman</surname>
      </author>
    </authorgroup>

    <abstract>

      <para>Jegliche Meldungen über Ungenauigkeiten oder sonstige Fehler in diesem Dokument sowie andere Beiträge sind sehr willkommen. Schicken Sie Ihre Vorschläge, Kritiken oder Anmerkungen an das <ulink url="mailto:tthurman@gnome.org">Entwicklerteam</ulink>.</para>

    </abstract>

    <copyright>
      <year>2008</year>
      <holder>Thomas Thurman</holder>
    </copyright>

    <legalnotice>
      <para>Das vorliegende Dokument kann gemäß den Bedingungen der GNU Free Documentation License (GFDL), Version 1.2 oder jeder späteren, von der Free Software Foundation veröffentlichten Version ohne unveränderbare Abschnitte sowie ohne Texte auf dem vorderen und hinteren Buchdeckel kopiert, verteilt und/oder modifiziert werden. Eine Kopie der GFDL erhalten Sie bei der Free Software Foundation auf deren Webseite oder schreiben Sie an: Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.</para>
    </legalnotice>

  </bookinfo>

<chapter id="sec-introduction">
<title>Einführung</title>

<para>Dies ist ein Artikel über die Erstellung von Themen für Metacity. Es wird noch daran gearbeitet, und es sind tiefgreifende Nachforschungen nötig, um Antworten zu finden. Es dürften Fehler enthalten sein, daher sind Korrekturen und Vorschläge herzlich willkommen.</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; <ulink url="http://en.wikipedia.org/wiki/Metacity#Themes">Wikipedia begins a sentence</ulink> with "Despite the incomplete state of Metacity theme development documentation", and though there <emphasis>is</emphasis> <ulink url="http://svn.gnome.org/viewvc/metacity/trunk/doc/theme-format.txt?view=markup">documentation in the source</ulink>, apparently not many people find it, and it's written more for programmers than theme designers.  Glynn Foster also wrote <ulink url="http://developer.gnome.org/doc/tutorials/metacity/metacity-themes.html">a very good introduction to Metacity themes</ulink> (<ulink url="http://home.arcor.de/rybaczyk/documents/tutorials/metacity/metacity-themes.de.html">[de]</ulink>) six years ago, but things have changed a little since then.  <ulink url="http://lists.freedesktop.org/archives/compiz/2006-September/000445.html">Metacity themes can also be used by Compiz</ulink>, and perhaps by other window managers for all I know.</para>

<para>So ist ein Metacity-Thema eine Reihe von Anweisungen, wie ein Fenster »dekoriert« werden soll, also wie der Rahmen gezeichnet werden soll. Wir nehmen an, dass Sie nicht alle Fenster genau gleich gestalten wollen. Daher ermöglicht es das Format, Details für die verschiedenen Arten von Fenstern anzugeben.</para>

<para>
<variablelist>
  <varlistentry>
    <term>Status:</term><listitem><para>Jedes Fenster muss sich in exakt einem Status befinden: <literal>normal</literal>, <literal>dialog</literal>, <literal>modal dialog</literal> (beispielsweise ein Dialog, der die Interaktion mit dem übrigen Programm verhindert), <literal>menu</literal> (aus dem Hauptfenster ausgegliedert, wird heute nur noch selten benutzt), <literal>utility</literal> (Paletten, Werkzeugkästen und ähnliche Dinge) und <literal>border</literal>. X erlaubt auch, das ein Fenster explizit nicht dekoriert wird. Wir stellen für diese Fenster keine Dekorationsanweisungen bereit.</para></listitem>
  </varlistentry>
  <varlistentry>
    <term>fokussiert</term><listitem><para>Jedes Fenster ist entweder aktiv (»fokussiert«) oder nicht.</para></listitem>
  </varlistentry>
  <varlistentry>
    <term>maximiert</term><listitem><para>Jedes Fenster ist entweder (vollständig) maximiert (nur horizontal oder nur vertikal zählt nicht) oder nicht.</para></listitem>
  </varlistentry>
  <varlistentry>
    <term>shaded</term><listitem><para>Jedes Fenster ist entweder eingerollt und zeigt dabei nur seine Titelleiste (aus unerfindlichen Gründen von manchen Leuten »shaded« genannt) oder nicht.</para></listitem>
  </varlistentry>
</variablelist>
</para>

<para>
<itemizedlist>
<listitem><para><emphasis>Falls ein Fenster nicht voll maximiert und nicht eingerollt ist</emphasis>, erlaubt es entweder horizontale Größenänderungen oder nicht.</para></listitem>
<listitem><para><emphasis>Falls ein Fenster nicht voll maximiert und nicht eingerollt ist</emphasis>, erlaubt es entweder vertikale Größenänderungen oder nicht.</para></listitem>
</itemizedlist>
</para>

</chapter>

<chapter>
<title>Inhalt der Datei</title>

<para>Die Datei muss entweder</para>

<para>
<itemizedlist>
<listitem><para>~/.themes/<varname>N</varname>/metacity-1/metacity-theme-<varname>V</varname>.xml für ein von Ihnen verwendetes Thema heißen, oder</para></listitem>
<listitem><para>/usr/share/themes/<varname>N</varname>/metacity-1/metacity-theme-<varname>V</varname>.xml für ein Thema, das für alle Benutzer installiert ist.</para></listitem>
</itemizedlist>
</para>

<para>Dabei ist <varname>N</varname> der Name des Themas und <varname>V</varname> die Formatversion. Die <ulink url="http://svn.gnome.org/viewvc/metacity?view=revision&amp;revision=2973">im Oktober 2006</ulink> eingeführte Version 2 bringt einige neue Funktionsmerkmale mit, die aber selten genutzt werden. Version 1 ist das Originalformat. Die Formate wurden solange bearbeitet, bis genug Aufwärts- und Abwärtskompatibilität gegeben war. <ulink url="http://bugzilla.gnome.org/show_bug.cgi?id=482165">Neue Funktionen</ulink> können nicht ohne neue Versionsnummer hinzugefügt werden. Daher kommen Verbesserungen recht selten, aber dafür in großen Brocken. <literal>metacity-1</literal> in den Namen ist ein Fossil und heißt keineswegs, das es sich in irgendeinem Zusammenhang um Version 1 handelt.</para>

<para>The metacity-theme-V.xml files are <ulink url="http://blogs.gnome.org/tthurman/2008/02/14/gmarkup/">GMarkup files</ulink>, 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 <ulink url="http://svn.gnome.org/viewvc/metacity/trunk/src/themes/Atlanta/metacity-theme-1.xml?view=markup">the current version of "Atlanta"</ulink>, one of the simplest themes, but even that is quite complicated-looking at first.</para>
<para>Nun lassen Sie uns einen Blick darauf werfen, was sich derzeit in den Dateien befindet. Wie in jeder XML-Datei sind &lt;!-- … &gt; Kommentare. Grundlegend sieht es so aus:</para>

<para>
<programlisting>
&lt;metacity_theme&gt;
&lt;!-- Helper stuff: --&gt;
&lt;info …&gt; &lt;!-- to be explained --&gt;
&lt;constant …&gt; &lt;!-- maybe; to be explained --&gt;

&lt;draw_ops …&gt; &lt;!-- maybe; to be explained --&gt;

&lt;!-- Things we build the top level onto: --&gt;
&lt;frame_geometry …&gt; &lt;!-- to be explained --&gt;

&lt;frame_style …&gt; &lt;!-- to be explained --&gt;
&lt;frame_style_set …&gt; &lt;!-- to be explained --&gt;

&lt;!-- And the top level: --&gt;

&lt;window type="normal" style_set="…" /&gt;
&lt;window type="dialog" style_set="…" /&gt;
&lt;window type="modal_dialog" style_set="…" /&gt;

&lt;window type="menu" style_set="…" /&gt;
&lt;window type="utility" style_set="…" /&gt;
&lt;window type="border" style_set="…" /&gt;

&lt;/metacity_theme&gt;
</programlisting>
</para>

</chapter>

<chapter>
<title>Matching windows</title>

<para>
<variablelist>
  <varlistentry>
    <term>window</term><listitem><para>In der obersten Ebene finden Sie eine Liste von &lt;window&gt;-Tags, einem für jeden erwähnten Fensterstatus. Das Argument style_set gibt jeweils den Namen eines frame_style_set an.</para></listitem>
  </varlistentry>
  <varlistentry>
    <term>frame_style_set:</term><listitem><para>Dies enthält Anweisungen zum Zeichnen der Fenster, abhängig davon, ob diese fokussiert sind oder nicht, eingerollt oder nicht, die vertikale oder horizontale Größenänderung oder Beides erlauben oder keines davon. Dies sieht so aus:</para></listitem>
  </varlistentry>
</variablelist>
</para>

<para>
<programlisting>
&lt;frame_style_set&gt;
&lt;frame focus="F" state="S" resize="R" style="N"/&gt;
&lt;frame… /&gt;

…
&lt;/frame_style_set&gt;
</programlisting>
</para>

<para>wobei:</para>

<para>
<variablelist>
  <varlistentry>
    <term>F</term><listitem><para>yes für fokussiert steht, no für unfokussiert.</para></listitem>
  </varlistentry>
  <varlistentry>
    <term>S</term><listitem><para>die Flags »shaded« und »maximized« kombiniert: normal, maximized, shaded, oder maximized_and_shaded.</para></listitem>
  </varlistentry>
  <varlistentry>
    <term>R</term><listitem><para>Größenänderungsrechte repräsentiert, die vom Fenster vorgegeben werden: none, vertical, horizontal, oder both. Rahmeneinstellungen für maximierte Fenster, deren Größe nicht veränderbar ist, haben dieses Attribut nicht.</para></listitem>
  </varlistentry>
</variablelist>
</para>

<para><varname>N</varname> ist der Name eines <literal>frame_style</literal>, der auf ein Fenster angewendet wird, das diese Attribute hat.</para>

<para>A <literal>frame_style_set</literal> tag may also have a "parent" 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 "parent" 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> Dies ist wahrscheinlich der komplizierteste Teil des ganzen Systems. Ein <literal>frame_style</literal> ist eine Reihe von <emphasis><literal>piece</literal></emphasis>s und <emphasis><literal>button</literal></emphasis>s. Es sieht so aus:</para>

<para>
<programlisting>
&lt;frame_style name="…" geometry="G"&gt;
&lt;piece position="P"&gt;
&lt;draw_ops&gt;
&lt;/draw_ops&gt;
&lt;/piece&gt;
…
&lt;button function="F" state="S" draw_ops="D"/&gt;

&lt;draw_ops&gt;
&lt;/draw_ops&gt;
&lt;/button&gt;
…
&lt;/frame_style&gt;
</programlisting>
</para>

<para>Die <literal>pieces</literal> sind Teile des Fensterrahmens. Wenn Metacity einen Fensterrahmen zeichnet, dann werden die verschiedenen Teile immer in der gleichen Reihenfolge gerendert. Die fett dargestellten Teile sind die möglichen Werte von P:</para>

<para>
<itemizedlist>
<listitem><para><literal>entire_background</literal>, gilt für de gesamten Fensterrahmen</para></listitem>

<listitem><para><literal>titlebar</literal>, gilt für den gesamten Hintergrund der Titelleiste</para></listitem>
<listitem><para><literal>titlebar_middle</literal>, der Teil der Titelleiste, der nicht die Ecken berührt</para></listitem>
<listitem><para><literal>left_titlebar_edge</literal>, <literal>right_titlebar_edge</literal>, <literal>top_titlebar_edge</literal> und <literal>bottom_titlebar_edge</literal></para></listitem>

<listitem><para><literal>title</literal>, genau der Bereich, in dem in der Titelleiste der Text erscheint</para></listitem>
<listitem><para><literal>left_edge</literal>, <literal>right_edge</literal> und <literal>bottom_edge</literal>, die Ecken des Rahmens (es gibt keine top_edge: das wäre dann top_titlebar_edge, nicht wahr?)</para></listitem>
<listitem><para><literal>overlay</literal>, was alles abdeckt, etwa so wie entire_background, aber zuletzt anstatt zuerst ausgeführt</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.  <ulink url="http://bugzilla.gnome.org/show_bug.cgi?id=107012">You might ask why we don't use SVG</ulink>; 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.</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 "maximize" 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 "state" 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 "normal", but the others are good to have too.</para>

<para>The "geometry" attribute of a <literal>frame_style</literal> tag is the name of a…</para>

</chapter>

<chapter>
<title>Geometrie</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 <ulink url="http://en.wikipedia.org/wiki/Dublin_Core">Dublin Core</ulink> 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, <ulink url="http://bugzilla.gnome.org/show_bug.cgi?id=524343">if anyone fancies fixing it</ulink>, 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 YourThemeName</command></para>
<para>and view it on the whole desktop using
<command>gsettings set org.gnome.desktop.wm.preferences theme YourThemeName</command></para>

<para>Whenever you change the selected theme in GSettings, 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 <ulink url="http://art.gnome.org/themes/metacity/">the art.gnome.org site</ulink>, or <ulink url="http://www.gnome-look.org/index.php?xcontentmode=101">the gnome-look site</ulink>.</para>

</chapter>

<chapter>
<title>Die Zukunft</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="normal+unfocused+maximized"&gt;…</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>