2.19.1 release.

2007-04-04  Elijah Newren  <newren gmail com>

        * NEWS: 2.19.1 release.

svn path=/trunk/; revision=3165

.cvsignore

@@ -15,6 +15,7 @@ ltconfig
 ltmain.sh
 stamp-h
 stamp-h.in
+stamp-h1
 stamp.h
 version.h
 config.h.in
@@ -28,3 +29,7 @@ COPYING
 intltool-*
 metacity.spec
 autom4te.cache
+compile
+depcomp
+omf.make
+xmldocs.make

HACKING

@@ -1,109 +1,299 @@
-Making a release
-===
+Intro...
 
-To make a release of metacity, do the following:
+Window managers have a few ways in which they are significantly different
+from other applications.  This file, combined with the code overview in
+doc/code-overview.txt, should hopefully provide a series of relatively
+quick pointers (hopefully only a few minutes each) to some of the places
+one can look to orient themselves and get started.  Some of this will be
+general to window managers on X, much will be specific to Metacity, and
+there's probably some information that's common to programs in general but
+is nonetheless useful.
 
- - check out a fresh copy from CVS
+Overview
+  Administrative issues
+  Minimal Building/Testing Environment
+  Relevant standards and X properties
+  Debugging and testing
+    Debugging logs
+    Adding information to the log
+    Valgrind
+    Testing Utilities
+  Technical gotchas to keep in mind
+  Other important reading
+    Extra reading
+    Ideas for tasks to work on
 
- - increment the version number in configure.in, 
-   see the comment above the version for the next fibonacci number
 
- - update the file NEWS based on the ChangeLog
+Administrative issues
+  Don't commit substantive code in here without asking hp@redhat.com.
+  Adding translations, no-brainer typo fixes, etc. is fine.
 
- - add a ChangeLog entry containing the version number 
-   you're releasing ("Released 2.5.4" or something)
-   so people can see which changes were before and after
-   a given release.
+  The code could use cleanup in a lot of places, feel free to do so.
 
- - "make distcheck" (DO NOT just "make dist" - pass the check!)
+  See http://developer.gnome.org/dotplan/for_maintainers.html for
+  information on how to make a release.  The only difference from those
+  instructions is that the minor version number of a Metacity release
+  should always be a number from the Fibonacci sequence.
 
- - if make distcheck fails, fix it.
+Minimal Building/Testing Environment
+  You do not need to _install_ a development version of Metacity to
+  build, run and test it; you can run it from some temporary
+  directory.  Also, you do not need to build all of Gnome in order to
+  build a development version of Metacity -- odds are, you may be able
+  to build metacity from CVS without building any other modules.
 
- - once distcheck succeeds, "cvs commit"
+  As long as you have gtk+ >= 2.10 with your distro (gtk+ >= 2.6 if
+  you manually revert the change from bug 348633), you should be able
+  to install your distro's development packages (e.g. gtk2-devel,
+  GConf2-devel, startup-notification-devel on Fedora; also, remember
+  to install the gnome-common package which is needed for building cvs
+  versions of Gnome modules like Metacity) as well as the standard
+  development tools (gcc, autoconf, automake, pkg-config, intltool,
+  and libtool) and be ready to build and test Metacity.  Steps to do
+  so:
 
- - if someone else made changes and the commit fails, 
-   you have to "cvs up" and run "make distcheck" again
+  $ cvs -q -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome \
+                  checkout metacity
+  $ cd metacity
+  $ ./autogen.sh --prefix /usr
+  $ make
+  $ ./src/metacity --replace
 
- - once the commit succeeds, WITHOUT cvs updating, "cvs tag
-   METACITY_X_Y_Z" where
-   X_Y_Z map to version X.Y.Z
+  Again, note that you do not need to run 'make install'.
 
- - scp the tarball to master.gnome.org
+Relevant standards and X properties
+  There are two documents that describe some basics about how window
+  managers should behave: the ICCCM (Inter-Client Communication Conventions
+  Manual) and EWMH (Extended Window Manager Hints).  You can find these at
+  the following locations:
+    ICCCM - http://tronche.com/gui/x/icccm/
+    EWMH  - :pserver:anoncvs@pdx.freedesktop.org:/cvs
+  The ICCCM is usually available in RPM or DEB format as well.  There is
+  actually an online version of the EWMH, but it is almost always woefully
+  out of date.  Just get it from cvs with these commands (the backslash
+  means include the stuff from the next line):
+    cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/icccm-extensions login
+    cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/icccm-extensions \
+      checkout wm-spec
 
- - run install-module on master.gnome.org to install the tarball 
-   on the ftp site
+  DO NOT GO AND READ THOSE THINGS.  THEY ARE REALLY, REALLY BORING.
 
-Misc stuff
-===
+  If you do, you'll probably end up catching up on your sleep instead of
+  hacking on Metacity. ;-)  Instead, just look at the table of contents and
+  glance at a page or two to get an idea of what's in there.  Then only
+  refer to it if you see something weird in the code and you don't know
+  what it is but has some funny looking name like you see in one of those
+  two documents.
 
-Don't commit substantive code in here without asking me,
-hp@redhat.com.  Adding translations, no-brainer typo fixes, etc.  is
-fine.
+  You can refer to the COMPLIANCE file for additional information on these
+  specifications and Metacity's compliance therewith.
 
-The script src/run-metacity.sh is useful to hack on the window manager. 
-It runs metacity in an Xnest. e.g.:
- CLIENTS=3 ./run-metacity.sh
-or 
- DEBUG=memprof ./run-metacity.sh
-or
- DEBUG_TEST=1 ./run-metacity-sh
-or whatever.
+  One of the major things those documents cover that are useful to learn
+  about immediately are X properties.  The right way to learn about those,
+  though, is through hand on experimentation with the xprop command (and
+  then look up things you find from xprop in those two manuals if you're
+  curious enough).  First, try running
+    xprop
+  in a terminal and click on one of the windows on your screen.  That gives
+  you the x properties for that window.  Look through them and get a basic
+  idea of what's there for kicks.  Note that you can get rid of some of the
+  verboseness by grepping out the _NET_WM_ICON stuff, i.e.
+    xprop | grep -v _NET_WM_ICON
+  Next, try running
+    xprop -root
+  in a terminal.  There's all the properties of the root window (which you
+  can think of as the "main" Xserver window).  You can also manually
+  specify individual windows that you want the properties of with
+    xprop -id <id>
+  if you know the id of the window in question.  You can get the id of a
+  given window by either running xwininfo, e.g.
+    xwininfo | grep "Window id" | cut -f 4 -d ' '
+  or by looking at the _NET_CLIENT_STACKING property of the root
+  window.  Finally, it can also be useful to add "-spy" (without the
+  quotes) to the xprop command to get it to continually monitor that
+  window and report any changes to you.
 
-The tool metacity-message can be used as follows:
- metacity-message reload-theme
- metacity-message restart
- metacity-message enable-keybindings
- metacity-message disable-keybindings
+Debugging information
+  Trying to run a window manager under a typical debugger, such as gdb,
+  unfortunately just doesn't work very well.  So, we have to resort to
+  other methods.
 
-metacity-window-demo is good for trying behavior of various kinds of window
-without launching a full desktop.
+  Debugging logs
 
-src/window.c is where all the guts of the window manager live. This is
-basically the only remotely scary file.
+  First, note that you can start a new version of metacity to replace the
+  existing one by running
+    metacity --replace
+  (which also comes in handy in the form "./src/metacity --replace" when
+  trying to quickly test a small change while hacking on metacity without
+  doing a full "make install", though I'm going off topic...)  This will
+  allow you to see any warnings printed at the terminal.  Sometimes it's
+  useful to have these directed to a logfile instead, which you can do by
+  running
+    METACITY_USE_LOGFILE=1 metacity --replace
+  The logfile it uses will be printed in the terminal.  Sometimes, it's
+  useful to get more information than just warnings.  You can set
+  METACITY_VERBOSE to do that, like so:
+    METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace
+  (note that METACITY_VERBOSE=1 can be problematic without
+  METACITY_USE_LOGFILE=1; avoid it unless running in from something that
+  won't be managed by the new Metacity--see bug 305091 for more details).
+  There are also other flags, such as METACITY_DEBUG, most of which I
+  haven't tried and don't know what they do.  Go to the source code
+  directory and run
+    grep "METACITY_" * | grep getenv
+  to find out what the other ones are.
 
-src/frames.c is the GtkWidget that handles drawing window frames.
+  Adding information to the log
 
-src/core.h defines the interface used by the GTK portion of the window
-manager to talk to the other portions. There's some cruft in here
-that's unused, since nearly all window operations have moved out of
-this file so frameless apps can have window operations.
+  Since we can't single step with a debugger, we often have to fall back to
+  the primitive method of getting information we want to know: adding
+  "print" statements.  Metacity has a fairly structured way to do this,
+  using the functions meta_warning, meta_topic, and meta_verbose.  All
+  three have the same basic format as printf, except that meta_topic also
+  takes a leading enumeration parameter to specify the type of message
+  being shown (makes it easier for grepping in a verbose log).  You'll find
+  tons of examples in the source code if you need them; just do a quick
+  grep or look in most any file.  Note that meta_topic and meta_verbose
+  messages only appear if verbosity is turned on.  I tend to frequently add
+  temporary meta_warning statements (or switch meta_topic or meta_verbose
+  ones to meta_warning ones) and then undo the changes once I've learned
+  the info that I needed.
 
-src/ui.h defines the interface the plain Xlib portion of the window
-manager uses to talk to the GTK portion.
+  There is also a meta_print_backtrace (which again is only active if
+  verbosity is turned on) that can also be useful if you want to learn how
+  a particular line of code gets called.  And, of course, there's always
+  g_assert if you want to make sure some section isn't executed (or isn't
+  executed under certain conditions).
 
-Files that include gdk.h or gtk.h are not supposed to include
-display.h or window.h or other core files.
+  Valgrind
 
-Files in the core (display.[hc], window.[hc]) are not supposed to
-include gdk.h or gtk.h.
+  Valgrind is awesome for finding memory leaks or corruption and
+  uninitialized variables.  But I also tend to use it in a non-traditional
+  way as a partial substitute for a normal debugger: it can provide me with
+  a stack trace of where metacity is crashing if I made a change that
+  caused it to do so, which is one of the major uses of debuggers.  (And,
+  what makes it cooler than a debugger is that there will also often be
+  warnings pinpointing the cause of the crash from either some kind of
+  simple memory corruption or an uninitialized variable).  Sometimes, when
+  I merely want to know what is calling a particular function I'll just
+  throw in an "int i; printf("%d\n", i);" just because valgrind will give
+  me a full stacktrace whenever it sees that uninitialized variable being
+  used (yes, I could use meta_print_backtrace, but that means I have to
+  turn verbosity on).
 
-src/theme.c and src/theme-parser.c have the theme system; this is
-well-modularized from the rest of the code, since the theme viewer app
-links to these files in addition to the WM itself.
+  To run metacity under valgrind, use options typical for any Gnome
+  program, such as
+    valgrind --logfile=metacity.log --tool=memcheck --num-callers=48 \
+    --leak-check=yes --leak-resolution=high --show-reachable=yes     \
+    ./src/metacity --replace
+  where, again, the backslashes mean to join all the stuff on the following
+  line with the previous one.
 
-When hacking, remember that you can have multiple screens. The code is
-also written to support multiple displays, but this is useless, since
-you can just run two copies of the WM. Also, an XKillClient() or
-shutdown on any display causes Xlib to exit the app, so it would be
-broken. So the multi-display thing is mostly just for code
-cleanliness.  Multi-screen on the other hand is important for some
-people.
+  However, there is a downside.  Things run a little bit slowly, and it
+  appears that you'll need about 1.5GB of ram, which unfortunately prevents
+  most people from trying this.
 
-Remember that strings stored in X properties are not in UTF-8, and
-they have to end up in UTF-8 before we try putting them through Pango.
+  Testing Utilities
 
-If you make any X request involving a client window, you have to
-meta_error_trap_push() around the call; this is not necessary for 
-X requests on the frame windows.
+  src/run-metacity.sh
+    The script src/run-metacity.sh is useful to hack on the window manager. 
+    It runs metacity in an Xnest. e.g.:
+      CLIENTS=3 ./run-metacity.sh
+    or 
+      DEBUG=memprof ./run-metacity.sh
+    or
+      DEBUG_TEST=1 ./run-metacity-sh
+    or whatever.
 
-Remember that not all windows have frames, and window->frame can 
-be NULL.
+  metacity-message
+    The tool metacity-message can be used as follows:
+      metacity-message reload-theme
+      metacity-message restart
+      metacity-message enable-keybindings
+      metacity-message disable-keybindings
+    The first of these is useful for testing themes, the second is just
+    another way (besides the --restart flag to metacity itself) of
+    restarting metacity, and the third is useful for testing Metacity when
+    running it under an Xnest (typically, the Metacity under the Xnest
+    wouldn't get keybinding notifications--making keyboard navigation not
+    work--but if you disable the keybindings for the global Metacity then
+    the Metacity under the Xnest can then get those keybinding notifications).
 
-The code could use cleanup in a lot of places, feel free to do so.
+  metacity-window-demo
+    metacity-window-demo is good for trying behavior of various kinds
+    of window without launching a full desktop.
 
-Metacity is ideally a fully ICCCM and EWMH-compliant window manager.
-Reading these specifications is a useful first step to understanding
-the role of a window manager on an X11 desktop and the standards and
-conventions on which X11 desktops are based.  Please refer to the
-COMPLIANCE file for additional information on these specifications and
-metacity's compliance therewith.
+Technical gotchas to keep in mind
+  Files that include gdk.h or gtk.h are not supposed to include
+  display.h or window.h or other core files.  Files in the core
+  (display.[hc], window.[hc]) are not supposed to include gdk.h or
+  gtk.h.  Reasons:
+
+    "Basically you don't want GDK most of the time. It adds
+    abstractions that cause problems, because they aren't designed to
+    be used in a WM where we do weird stuff (display grabs, and just
+    being the WM). At best GDK adds inefficiency, at worst it breaks
+    things in weird ways where you have to be a GDK guru to figure
+    them out. Owen also told me that they didn't want to start adding
+    a lot of hacks to GDK to let a WM use it; we both agreed back in
+    the mists of time that metacity would only use it for the "UI"
+    bits as it does.
+
+    Having the split in the source code contains and makes very clear
+    the interface between the WM and GDK/GTK. This keeps people from
+    introducing extra GDK/GTK usage when it isn't needed or
+    appropriate. Also, it speeds up the compilation a bit, though this
+    was perhaps more relevant 5 years ago than it is now.
+
+    There was also a very old worry that the GDK stuff might have to
+    be in a separate process to work right; that turned out to be
+    untrue. Though who knows what issues the CM will introduce."
+
+  Remember that strings stored in X properties are not in UTF-8, and they
+  have to end up in UTF-8 before we try putting them through Pango.
+
+  If you make any X request involving a client window, you have to
+  meta_error_trap_push() around the call; this is not necessary for X
+  requests on the frame windows.
+
+  Remember that not all windows have frames, and window->frame can be NULL.
+
+Other important reading & where to get started
+  Extra reading
+
+  There are some other important things to read to get oriented as well.
+  These are:
+    http://pobox.com/~hp/features.html
+    rationales.txt
+    doc/code-overview.txt
+
+  It pays to read http://pobox.com/~hp/features.html in order
+  to understand the philosophy of Metacity.
+
+  The rationales.txt file has two things: (1) a list of design choices with
+  links in the form of bugzilla bugs that discuss the issue, and (2) a list
+  outstanding bug categories, each of which is tracked by a particular
+  tracker bug in bugzilla from which you can find several closely related
+  bug reports.
+
+  doc/code-overview.txt provides a fairly good overview of the code,
+  including coverage of the function of the various files, the main
+  structures and their relationships, and places to start looking in the
+  code tailored to general categories of tasks.
+
+  Ideas for tasks to work on
+
+  There are a variety of things you could work on in the code.  You may
+  have ideas of your own, but in case you don't, let me provide a list of
+  ideas you could choose from:
+
+  If you're ambitious, there's a list of things Havoc made that he'd really
+  like to see tackled, which you can find at
+  http://log.ometer.com/2004-05.html.  Be sure to double check with someone
+  to make sure the item is still relevant if you're interested in one of
+  these.  Another place to look for ideas, of course, is bugzilla.  One can
+  just do queries and look for things that look fixable.
+
+  However, perhaps the best way of getting ideas of related tasks to work
+  on, is to look at the second half of the rationales.txt file, which tries
+  to group bugs by type.

MAINTAINERS

@@ -0,0 +1,32 @@
+Currently active maintainers
+--------------------------------
+Elijah Newren (newren  gmail com)
+  - Usually won't touch the theme bugs (isn't interested) or the
+    compositor (until open source nvidia drivers are up to snuff).
+    Tends to be most interested in libwnck/gtk interactions, focus
+    issues, constraints problems, and raising/stacking, but works on
+    just about anything other than themes and the compositor.
+
+Thomas Thurman (thomas  thurman org uk)
+  - Responsible for all theme bugs and the compositor (thank goodness
+    Thomas got involved, eh?).  I'm sure he'll replace this sentence
+    with his interests when he reads it.  ;-)
+
+
+Semi-active maintainers
+--------------------------------
+Havoc Pennington (hp  redhat com)
+  - Original author.  Doesn't patch metacity anymore, but is active in
+    answering questions, responding to bugs, providing very helpful
+    suggestions and insight, and even assisting with debugging.
+
+
+Important historical figureheads
+--------------------------------
+Rob Adams (readams  readams net)
+  - Was the main maintainer of metacity for a while; particular areas
+    of focus included xinerama, placement, and an older version of the
+    constraints code.  Still responds to bugs every once in a while.
+
+Søren Sandmann (sandmann  redhat com)
+  - Wrote most of the current compositing manager code + libcm

Makefile.am

@@ -1,5 +1,7 @@
 
 SUBDIRS=src po doc
 
-EXTRA_DIST=HACKING rationales.txt \
+EXTRA_DIST = HACKING MAINTAINERS rationales.txt \
 	intltool-extract.in intltool-merge.in intltool-update.in
+
+DISTCLEANFILES = intltool-extract intltool-merge intltool-update po/stamp-it po/.intltool-merge-cache

README

@@ -6,9 +6,11 @@ on UNIX keyboards.
 The first release of Metacity was version 2.3. Metacity has no need for
 your petty hangups about version numbers.
 
-The stable releases so far are 2.4.x, 2.6.x, 2.8.0, 2.8.1, 2.8.1.x, 2.8.5
+The stable releases so far are 2.4.x, 2.6.x, 2.8.[01], 2.8.1.x, 2.8.5-,
+2.10.x, 2.12.x, 2.14.x, 2.16.x.
 
-Unstable branches are 2.3.x, 2.5.x, 2.8.2-4)
+Unstable branches are 2.3.x, 2.5.x, 2.8.2-4, 2.9.x, 2.11.x, 2.13.x,
+2.15.x, 2.17.x.
 
 COMPILING METACITY
 ===
@@ -314,8 +316,8 @@ A: Metacity only stores sizes/positions for apps that are session
    archaic than twm - and you should flame them. ;-)
 
    Docs on session management:
-    ftp://ftp.x.org/pub/R6.4/xc/doc/hardcopy/SM/xsmp.PS.gz
-    ftp://ftp.x.org:21/pub/R6.4/xc/doc/hardcopy/SM/SMlib.PS.gz
+    http://www.fifi.org/doc/xspecs/xsmp.txt.gz
+    http://www.fifi.org/doc/xspecs/SMlib.txt.gz
 
    See also the ICCCM section on SM. For GNOME apps, use the
    GnomeClient object. For a simple example of using libSM directly,

autogen.sh

@@ -4,153 +4,18 @@
 srcdir=`dirname $0`
 test -z "$srcdir" && srcdir=.
 
-ORIGDIR=`pwd`
-cd $srcdir
-PROJECT=metacity
-TEST_TYPE=-f
-FILE=src/display.c
+PKG_NAME="metacity"
+REQUIRED_AUTOMAKE_VERSION=1.7
 
-DIE=0
-
-AUTOMAKE=automake-1.4
-ACLOCAL=aclocal-1.4
-
-($AUTOMAKE --version) < /dev/null > /dev/null 2>&1 || {
-        AUTOMAKE=automake
-        ACLOCAL=aclocal
+(test -f $srcdir/configure.in \
+  && test -d $srcdir/src) || {
+    echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
+    echo " top-level metacity directory"
+    exit 1
 }
 
-(autoconf --version) < /dev/null > /dev/null 2>&1 || {
-	echo
-	echo "You must have autoconf installed to compile $PROJECT."
-	echo "Download the appropriate package for your distribution,"
-	echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/"
-	DIE=1
+which gnome-autogen.sh || {
+    echo "You need to install gnome-common from the GNOME CVS"
+    exit 1
 }
-
-($AUTOMAKE --version) < /dev/null > /dev/null 2>&1 || {
-	echo
-	echo "You must have automake installed to compile $PROJECT."
-	echo "Get ftp://sourceware.cygnus.com/pub/automake/automake-1.4.tar.gz"
-	echo "(or a newer version if it is available)"
-	DIE=1
-}
-
-(grep "^AM_PROG_LIBTOOL" configure.in >/dev/null) && {
-  (libtool --version) < /dev/null > /dev/null 2>&1 || {
-    echo
-    echo "**Error**: You must have \`libtool' installed to compile $PROJECT."
-    echo "Get ftp://ftp.gnu.org/pub/gnu/libtool-1.2d.tar.gz"
-    echo "(or a newer version if it is available)"
-    DIE=1
-  }
-}
-
-CONFIGURE=configure.in
-if grep "^AM_[A-Z0-9_]\{1,\}_GETTEXT" "$CONFIGURE" >/dev/null; then
-  if grep "sed.*POTFILES" "$CONFIGURE" >/dev/null; then
-    GETTEXTIZE=""
-  else
-    if grep "^AM_GLIB_GNU_GETTEXT" "$CONFIGURE" >/dev/null; then
-      GETTEXTIZE="glib-gettextize"
-      GETTEXTIZE_URL="ftp://ftp.gtk.org/pub/gtk/v2.0/glib-2.0.0.tar.gz"
-    else
-      GETTEXTIZE="gettextize"
-      GETTEXTIZE_URL="ftp://alpha.gnu.org/gnu/gettext-0.10.35.tar.gz"
-    fi
-
-    $GETTEXTIZE --version < /dev/null > /dev/null 2>&1
-    if test $? -ne 0; then
-      echo
-      echo "**Error**: You must have \`$GETTEXTIZE' installed to compile $PKG_NAME."
-      echo "Get $GETTEXTIZE_URL"
-      echo "(or a newer version if it is available)"
-      DIE=1
-    fi
-  fi
-fi
-
-if test "$DIE" -eq 1; then
-	exit 1
-fi
-
-test $TEST_TYPE $FILE || {
-	echo "You must run this script in the top-level $PROJECT directory"
-	exit 1
-}
-
-if test -z "$*"; then
-	echo "I am going to run ./configure with no arguments - if you wish "
-        echo "to pass any to it, please specify them on the $0 command line."
-fi
-
-case $CC in
-*xlc | *xlc\ * | *lcc | *lcc\ *) am_opt=--include-deps;;
-esac
-
-for coin in .
-do 
-  dr=`dirname $coin`
-  if test -f $dr/NO-AUTO-GEN; then
-    echo skipping $dr -- flagged as no auto-gen
-  else
-    echo processing $dr
-    macrodirs=`sed -n -e 's,AM_ACLOCAL_INCLUDE(\(.*\)),\1,gp' < $coin`
-    ( cd $dr
-      aclocalinclude="$ACLOCAL_FLAGS"
-      for k in $macrodirs; do
-  	if test -d $k; then
-          aclocalinclude="$aclocalinclude -I $k"
-  	##else 
-	##  echo "**Warning**: No such directory \`$k'.  Ignored."
-        fi
-      done
-      if grep "^AM_GLIB_GNU_GETTEXT" configure.in >/dev/null; then
-	if grep "sed.*POTFILES" configure.in >/dev/null; then
-	  : do nothing -- we still have an old unmodified configure.in
-	else
-	  echo "Creating $dr/aclocal.m4 ..."
-	  test -r $dr/aclocal.m4 || touch $dr/aclocal.m4
-	  echo "Running glib-gettextize...  Ignore non-fatal messages."
-	  echo "no" | glib-gettextize --force --copy
-	  echo "Making $dr/aclocal.m4 writable ..."
-	  test -r $dr/aclocal.m4 && chmod u+w $dr/aclocal.m4
-        fi
-      fi
-      if grep "^AC_PROG_INTLTOOL" configure.in >/dev/null; then
-        echo "Running intltoolize..."
-        intltoolize --force --copy --automake
-      fi
-      if grep "^AM_PROG_LIBTOOL" configure.in >/dev/null; then
-	echo "Running libtoolize..."
-	libtoolize --force --copy
-      fi
-
-      echo "Running $ACLOCAL $aclocalinclude ..."
-      $ACLOCAL $aclocalinclude
-
-      if grep "^AM_CONFIG_HEADER" configure.in >/dev/null; then
-	echo "Running autoheader..."
-	autoheader
-      fi
-
-      echo "Running $AUTOMAKE --gnu $am_opt ..."
-      $AUTOMAKE --add-missing --gnu $am_opt
-
-      echo "Running autoconf ..."
-      autoconf
-    )
-  fi
-done
-
-conf_flags="--enable-maintainer-mode --enable-compile-warnings" #--enable-iso-c
-
-cd "$ORIGDIR"
-
-if test x$NOCONFIGURE = x; then
-  echo Running $srcdir/configure $conf_flags "$@" ...
-  $srcdir/configure $conf_flags "$@" \
-  && echo Now type \`make\' to compile $PROJECT  || exit 1
-else
-  echo Skipping configure process.
-fi
+USE_GNOME2_MACROS=1 USE_COMMON_DOC_BUILD=yes . gnome-autogen.sh

configure.in

@@ -1,23 +1,30 @@
 AC_PREREQ(2.50)
-AC_INIT(src/display.c)
 
-AM_CONFIG_HEADER(config.h)
+m4_define([metacity_major_version], [2])
+m4_define([metacity_minor_version], [19])
+# Fibonacci sequence for micro version numbering:
+# 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987
+m4_define([metacity_micro_version], [1])
 
-# we'll hold the 2.8.x versioning for GNOME 2.8, it was also used
-# for GNOME 2.6, then after GNOME 2.8 we'll have the numbers synced
-# with GNOME
-AM_INIT_AUTOMAKE(metacity, 2.8.5)
+m4_define([metacity_version],
+          [metacity_major_version.metacity_minor_version.metacity_micro_version])
+AC_INIT([metacity], [metacity_version],
+        [http://bugzilla.gnome.org/enter_bug.cgi?product=metacity])
+
+AC_CONFIG_SRCDIR(src/display.c)
+AC_CONFIG_HEADERS(config.h)
+
+AM_INIT_AUTOMAKE
+AM_MAINTAINER_MODE
 
 # Honor aclocal flags
-ACLOCAL="$ACLOCAL $ACLOCAL_FLAGS"
+AC_SUBST(ACLOCAL_AMFLAGS, "\${ACLOCAL_FLAGS}")
 
 GETTEXT_PACKAGE=metacity
 AC_SUBST(GETTEXT_PACKAGE)
 AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE,"$GETTEXT_PACKAGE",[Name of default gettext domain])
 
-AM_MAINTAINER_MODE
-
-AC_PROG_INTLTOOL([0.21])
+IT_PROG_INTLTOOL([0.34.90])
 AC_PROG_CC
 AC_ISC_POSIX
 AC_HEADER_STDC
@@ -100,53 +107,68 @@ if test "x$GCC" = "xyes"; then
 fi
 changequote([,])dnl
 
-METACITY_PC_MODULES='gtk+-2.0 >= 2.2.0 pango >= 1.2.0'
+METACITY_PC_MODULES='gtk+-2.0 >= 2.10.0 pango >= 1.2.0'
 
-AC_ARG_ENABLE(config-dialog,      [  --enable-config-dialog      enable the config dialog that you need with GNOME 2.0 (obsolete with GNOME 2.2)],,enable_config_dialog=no)
-
-AM_CONDITIONAL(BUILD_CONFIG_DIALOG, test x$enable_config_dialog = xyes)
-if test x$enable_config_dialog = xyes; then
-    AC_DEFINE(BUILD_CONFIG_DIALOG,1,[Build configuration dialog])
-fi
-
-AC_ARG_ENABLE(gconf,              [  --disable-gconf             disable gconf usage, for embedded/size-sensitive non-GNOME builds],,enable_gconf=yes)
+AC_ARG_ENABLE(gconf,
+  AC_HELP_STRING([--disable-gconf],
+                 [disable gconf usage, for embedded/size-sensitive non-GNOME builds]),,
+  enable_gconf=yes)
 
 if test x$enable_gconf = xyes; then
     AC_DEFINE(HAVE_GCONF,1,[Build with gconf support])
     METACITY_PC_MODULES="$METACITY_PC_MODULES gconf-2.0 >= 1.2.0"
 fi
 
-AC_ARG_ENABLE(verbose-mode,       [  --disable-verbose             disable metacity's ability to do verbose logging, for embedded/size-sensitive custom builds],,enable_verbose_mode=yes)
+AC_ARG_ENABLE(verbose-mode,
+  AC_HELP_STRING([--disable-verbose],
+                 [disable metacity's ability to do verbose logging, for embedded/size-sensitive custom builds]),,
+  enable_verbose_mode=yes)
 
 if test x$enable_verbose_mode = xyes; then
     AC_DEFINE(WITH_VERBOSE_MODE,1,[Build with verbose mode support])
 fi
 
-AC_ARG_ENABLE(sm,       [  --disable-sm             disable metacity's session management support, for embedded/size-sensitive custom non-GNOME builds],,enable_sm=auto)
+AC_ARG_ENABLE(sm,
+  AC_HELP_STRING([--disable-sm],
+                 [disable metacity's session management support, for embedded/size-sensitive custom non-GNOME builds]),,
+  enable_sm=auto)
 
-AC_ARG_ENABLE(startup-notification,   [  --disable-startup-notification             disable metacity's startup notification support, for embedded/size-sensitive custom non-GNOME builds],,enable_startup_notification=auto)
+AC_ARG_ENABLE(startup-notification,
+  AC_HELP_STRING([--disable-startup-notification],
+                 [disable metacity's startup notification support, for embedded/size-sensitive custom non-GNOME builds]),,
+  enable_startup_notification=auto)
 
-AC_ARG_ENABLE(compositor,   [  --disable-compositor             disable metacity's compositing manager],,enable_compositor=auto)
+AC_ARG_ENABLE(compositor,
+  AC_HELP_STRING([--disable-compositor],
+                 [disable metacity's compositing manager]),,
+  enable_compositor=auto)
 
-AC_ARG_ENABLE(xsync,       [  --disable-xsync             disable metacity's use of the XSync extension],,enable_xsync=auto)
+AC_ARG_ENABLE(xsync,
+  AC_HELP_STRING([--disable-xsync],
+                 [disable metacity's use of the XSync extension]),,
+  enable_xsync=auto)
 
-AC_ARG_ENABLE(render,       [  --disable-render             disable metacity's use of the RENDER extension],,enable_render=auto)
+AC_ARG_ENABLE(render,
+  AC_HELP_STRING([--disable-render],
+                 [disable metacity's use of the RENDER extension]),,
+  enable_render=auto)
 
-AC_ARG_ENABLE(shape,       [  --disable-shape             disable metacity's use of the shaped window extension],,enable_shape=auto)
+AC_ARG_ENABLE(shape,
+  AC_HELP_STRING([--disable-shape],
+                 [disable metacity's use of the shaped window extension]),,
+  enable_shape=auto)
 
 ## try definining HAVE_BACKTRACE
 AC_CHECK_HEADERS(execinfo.h, [AC_CHECK_FUNCS(backtrace)])
 
-ALL_LINGUAS="am ar az be bg bn bs ca cs cy da de el en_CA en_GB es et eu fa fi fr ga gl gu he hi hr hu id is it ja ko lt lv mk ml mn ms nb nl nn no or pa pl pt pt_BR ro ru sl sk sq sr sr@Latn sv ta th tk tr uk vi wa zh_CN zh_TW"
 AM_GLIB_GNU_GETTEXT
 
 ## here we get the flags we'll actually use
-PKG_CHECK_MODULES(METACITY_MESSAGE, gtk+-2.0 >= 2.2.0)
-PKG_CHECK_MODULES(METACITY_WINDOW_DEMO, gtk+-2.0 >= 2.2.0)
-
-if test x$enable_config_dialog = xyes; then
-   PKG_CHECK_MODULES(METACITY_PROPS, gtk+-2.0 >= 2.2.0 gconf-2.0 >= 1.1.9 libglade-2.0)
-fi
+# GOptionEntry requires	glib-2.6.0    
+PKG_CHECK_MODULES(ALL, glib-2.0 >= 2.6.0)
+# gtk_window_set_icon_name requires gtk2+-2.60
+PKG_CHECK_MODULES(METACITY_MESSAGE, gtk+-2.0 >= 2.6.0)
+PKG_CHECK_MODULES(METACITY_WINDOW_DEMO, gtk+-2.0 >= 2.6.0)
 
 if $PKG_CONFIG --atleast-version 1.2.0 pangoxft; then
    echo "pangoxft found"
@@ -184,7 +206,7 @@ fi
 ## or the render-specific check later
 have_xrender=no
 
-XCOMPOSITE_VERSION=1.0
+XCOMPOSITE_VERSION=0.2
 AC_MSG_CHECKING([Xcomposite >= $XCOMPOSITE_VERSION])
 if $PKG_CONFIG --atleast-version $XCOMPOSITE_VERSION xcomposite; then
    have_xcomposite=yes
@@ -197,7 +219,7 @@ if test x$enable_compositor = xyes; then
    have_xcomposite=yes
    echo "CompositeExt support forced on"
 elif test x$enable_compositor = xauto; then
-   echo "Not building compositing manager by default now, must enable explicitly to get it. And it doesn't work, so don't bother unless you want to hack on it..."
+   echo "Not building compositing manager by default now, must enable explicitly to get it."
    have_xcomposite=no
 else
    have_xcomposite=no
@@ -205,7 +227,7 @@ fi
 
 if test x$have_xcomposite = xyes; then
   echo "Building with CompositeExt"
-  METACITY_PC_MODULES="$METACITY_PC_MODULES xcomposite >= $XCOMPOSITE_VERSION xfixes xrender xdamage"
+  METACITY_PC_MODULES="$METACITY_PC_MODULES xcomposite >= $XCOMPOSITE_VERSION xfixes xrender xdamage cm"
   AC_DEFINE(HAVE_COMPOSITE_EXTENSIONS, , [Building with compositing manager support])
 
   ## force on render also
@@ -244,6 +266,20 @@ if test x$have_xrender = xyes; then
   AC_DEFINE(HAVE_RENDER, , [Building with Render extension support])
 fi
 
+AC_MSG_CHECKING([Xcursor])
+if $PKG_CONFIG xcursor; then
+     have_xcursor=yes
+  else
+     have_xcursor=no
+  fi
+  AC_MSG_RESULT($have_xcursor)
+
+if test x$have_xcursor = xyes; then
+  echo "Building with Xcursor"
+  METACITY_PC_MODULES="$METACITY_PC_MODULES xcursor"
+  AC_DEFINE(HAVE_XCURSOR, , [Building with Xcursor support]) 
+fi
+
 PKG_CHECK_MODULES(METACITY, $METACITY_PC_MODULES)
 
 AC_PATH_XTRA
@@ -254,8 +290,10 @@ ALL_X_LIBS="$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
 metacity_save_cppflags="$CPPFLAGS"
 CPPFLAGS="$CPPFLAGS $X_CFLAGS"
 
-AC_ARG_ENABLE(xinerama,[  --disable-xinerama          disable metacity's use of the Xinerama extension],
-              try_xinerama=$enable_xinerama,try_xinerama=yes)
+AC_ARG_ENABLE(xinerama,
+  AC_HELP_STRING([--disable-xinerama],
+                 [disable metacity's use of the Xinerama extension]),
+  try_xinerama=$enable_xinerama,try_xinerama=yes)
 
 use_solaris_xinerama=no
 use_xfree_xinerama=no
@@ -371,10 +409,10 @@ if test "x$found_xsync" = "xyes"; then
    AC_DEFINE(HAVE_XSYNC, , [Have the Xsync extension library])
 fi
 
-METACITY_LIBS="$XSYNC_LIBS $RANDR_LIBS $SHAPE_LIBS $X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS $METACITY_LIBS"
-METACITY_MESSAGE_LIBS="$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS $METACITY_MESSAGE_LIBS"
-METACITY_WINDOW_DEMO_LIBS="$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS $METACITY_WINDOW_DEMO_LIBS"
-METACITY_PROPS_LIBS="$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS $METACITY_PROPS_LIBS"
+METACITY_LIBS="$METACITY_LIBS $XSYNC_LIBS $RANDR_LIBS $SHAPE_LIBS $X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
+METACITY_MESSAGE_LIBS="$METACITY_MESSAGE_LIBS $X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
+METACITY_WINDOW_DEMO_LIBS="$METACITY_WINDOW_DEMO_LIBS $X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
+METACITY_PROPS_LIBS="$METACITY_PROPS_LIBS $X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
 
 found_sm=no
 case "$METACITY_LIBS" in
@@ -430,11 +468,15 @@ if test x$enable_gconf = xyes; then
    fi
 
    AM_GCONF_SOURCE_2
+else
+  GCONF_SCHEMAS_INSTALL_TRUE='#'
+  GCONF_SCHEMAS_INSTALL_FALSE=
 fi
 
-AC_OUTPUT([
+AC_CONFIG_FILES([
 Makefile
 doc/Makefile
+doc/man/Makefile
 src/Makefile
 src/wm-tester/Makefile
 src/libmetacity-private.pc
@@ -443,13 +485,12 @@ src/themes/Makefile
 po/Makefile.in
 ])
 
+AC_OUTPUT
+
 if test x$enable_gconf = xno; then
         echo "*** WARNING WARNING WARNING WARNING WARNING"
-        echo "*** Building without GConf"
-        echo "*** This means there's no way to change prefs except"
-        echo "*** hacking source code, at least for now."
-        echo "*** Also, some prefs may have broken defaults."
-        echo "*** Patches needed for a simple no-gconf config file."
+        echo "*** Building without GConf.  This means there's no"
+        echo "*** way to change prefs except hacking source code."
         echo "*** This is intended for embedded systems etc., not for normal use."
 fi
 
@@ -479,6 +520,15 @@ metacity-$VERSION:
 	Resize-and-rotate:        ${found_randr}
 	Xsync:                    ${found_xsync}
 	Render:                   ${have_xrender}
-        Deprecated config dialog: ${enable_config_dialog}
+	Xcursor:                  ${have_xcursor}
 "
-# echo "This is the UNSTABLE branch of metacity, use 2.8.1.x for stable (gnome-2-6 branch in CVS)"
+
+METACITY_MINOR_VERSION=metacity_minor_version
+if test $(( $(echo $METACITY_MINOR_VERSION) %2)) == "1"; then
+   stable_version=$(( ($METACITY_MINOR_VERSION / 2) * 2))
+   echo "This is the UNSTABLE branch of metacity"
+   echo -n "Use 2.$stable_version.x for stable "
+   echo    "(gnome-2-$stable_version branch in CVS)"
+else
+   echo "This is the stable branch of metacity"
+fi

doc/Makefile.am

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

doc/code-overview.txt

@@ -0,0 +1,185 @@
+This is not meant to be comprehensive by any means.  Rather it is
+meant as just a brief overview of some of the bigger structures and
+files, with guides for a variety of task categories providing places
+to start looking in the code and things to look for.
+
+Overview
+  Jobs of various files
+  Major data structures and their relationships
+  Getting started -- where to look
+
+
+Jobs of various files
+  src/window.c is where all the guts of the window manager live. This is
+  basically the only remotely scary file.
+
+  src/frames.c is the GtkWidget that handles drawing window frames.
+
+  src/core.h defines the interface used by the GTK portion of the window
+  manager to talk to the other portions. There's some cruft in here that's
+  unused, since nearly all window operations have moved out of this file so
+  frameless apps can have window operations.
+
+  src/ui.h defines the interface the plain Xlib portion of the window
+  manager uses to talk to the GTK portion.
+
+  src/theme.c and src/theme-parser.c have the theme system; this is
+  well-modularized from the rest of the code, since the theme viewer app
+  links to these files in addition to the WM itself.
+
+Major data structures and their relationships
+  Major structs have a "Meta" prefix, thus MetaDisplay, MetaScreen,
+  MetaWindow, etc.  This serves as a way of namespacing in C.  It also has
+  the side effect of avoiding conflicts with common names that X already
+  uses such as Display, Screen, Window, etc.  Note that when I refer to a
+  display below, I'm meaning a MetaDisplay and not a Display.
+
+  Don't confuse displays and screens.  While Metacity can run with multiple
+  displays, it is kind of useless since you might as well just run two
+  copies of Metacity.  However, having multiple screens per display is
+  useful and increasingly common (known as "multiscreen" and "xinerama"
+  setups, where users make use of more than one monitor).  You should
+  basically think of a display as a combination of one or more monitors
+  with a single keyboard (...and usually only one mouse).
+
+  There is also a significant difference between multiscreen and xinerama
+  as well.  Basically, each MetaScreen is a root window (root node in the
+  tree of windows).  With Xinerama, a single root window appears to span
+  multiple monitors, whereas with multiscreen a root window is confined to
+  a single monitor.  To re-emphasize the distinction between a display and
+  a screen, the pointer and keyboard are shared between all root windows
+  for a given display.
+
+  The display keeps track of a lot of various global quantities, but in
+  particular has a compositor and a list (GList) of screens.
+
+  A compositor is an opaque structure (only defined in compositor.c),
+  meaning that you'll only reference the API for it.  It handles (or will
+  handle) cool stuff with the new X extensions, such as smooth resizing and
+  alpha transparency.
+
+  A screen keeps track of a number of quantities as well, in particular a
+  stack and a list of workspaces.
+
+  A stack is basically a list of windows, and the depth order they have
+  relative to each other (which thus determines which windows are on top
+  and which are obscured).
+
+  A workspace mostly contains a list of windows for the workspace, but also
+  has a few other quantities as well (a list of struts which are areas
+  where windows should not be placed and an mru_list or "most recently used
+  window list").
+
+  A window has a huge list of quantities for keeping track of things about
+  a window on the screen.  (We want to avoid making this list larger
+  because the memory for all these quantities is per window.)  One item in
+  particular that a window has, though, is a frame.
+
+  A frame is the decorations that surround the window (i.e. the titlebar and
+  the minimize and close buttons and the part that you can use to resize),
+  and contains a handful of variables related to that, but no other major
+  structures.
+
+Getting started -- where to look
+  Getting started on developing free software projects can often be like
+  being dropped off in a town that is unknown to you and being told to make
+  a map, when various road and building signs are missing or fading.  To
+  try to alleviate that initial difficulty in orientation, below I list a
+  variety of general task categories with file, function, variable, and x
+  property names that may be useful to fixing bugs or writing features that
+  fall within that category.
+
+  First, though, it's useful to note that most event and message passing
+  goes through display.c:event_callback(), so that's often a good place to
+  start reading for general familiarity with the code (actually, I'd
+  suggest skipping down to the first switch statement within that
+  function).  Of course, not all events go through that function, as there
+  are a few other places that handle events too such as frames.c.
+
+  Anyway, without further ado, here are the categories and (hopefully)
+  useful things to look at for each:
+
+    Focus issues (i.e. issues with which window is active):
+      doc/how-to-get-focus-right.txt
+      meta_workspace_focus_default_window
+      _NET_ACTIVE_WINDOW
+      _NET_WM_USER_TIME
+      meta_window_focus
+      meta_display_(set_input|focus_the_no)_focus_window
+      XSetInputFocus (only for purposes of understanding how X focus/input works)
+      CurrentTime (mostly, you should just think "Bad; don't use it")
+
+    Compositor stuff (X extension for eye candy like transparency):
+      compositor.c
+      The luminocity module in CVS
+
+    Window depth (i.e. stacking or lowering/raising) issues:
+      stack.c
+      _NET_CLIENT_LIST_STACKING
+      transient_for
+      WM_TRANSIENT_FOR
+      meta_window_(raise|lower)
+      _NET_WM_WINDOW_TYPE
+      _NET_WM_MOUSE_ACTION/_NET_WM_TAKE_ACTIVITY? (aren't yet in EWMH)
+
+    Window placement issues:
+      place.c
+      constraints.c
+      _NET_WM_STRUT
+      WM_SIZE_HINTS
+
+    Moving and resizing issues:
+      constraints.c
+      update_move
+      update_resize
+      meta_window_handle_mouse_grab_op_event
+      _NET_MOVERESIZE_WINDOW
+      _NET_WM_STRUT
+
+    Drag and drop issues:
+      the XDND protocol (see http://www.newplanetsoftware.com/xdnd/ and
+        http://freedesktop.org/Standards/XDND)
+      _NET_WM_MOUSE_ACTION/_NET_WM_TAKE_ACTIVITY (aren't yet in EWMH)
+      A general pointer: what causes the difficulty here is that when the
+        application receives a mouse click to start a drag, it does a grab
+        so that the window manager doesn't get any further events; thus
+        correcting things require standards so that applications and window
+        managers can collaborate correctly
+
+    Theme issues: ???
+      doc/theme-format.txt
+      theme.c
+      theme-parser.c
+      (ui.c, core.c, frames.c, frame.c?  I dunno...)
+
+    Session management issues: ???
+      session.c
+      http://www.x.org/X11R6.8.1/doc/SM/xsmp.pdf ?
+      http://www.x.org/X11R6.8.1/doc/SM/SMlib.pdf ?
+      meta_window_apply_session_info
+
+    Tasklist and Workspace switcher issues:
+      window-props.c
+      various functions in screen.c (especially ones using XChangeProperty)
+      xprops.c
+      The libwnck module in cvs
+      meta_window_client_message
+      Lots of the EWMH
+
+    Window and workspace selection/changing issues:
+      tabpopup.c
+      keybindings.c, functions: *_workspace*, *_tab_*
+      meta_screen_ensure_*_popup
+      display.c, functions: *_tab*
+
+    Key and mouse binding actions:
+      keybindings.c
+      meta_frames_button_(press|release)_event
+      display.c: event_callback, but only the (Key|Button)_(Press|Release) cases
+
+    Xinerama and multiscreen: ???
+      In general, just search for Xinerama, but in particular see
+      screen.c
+      window.c
+      place.c
+      constraints.c

doc/compositor-control.txt

@@ -0,0 +1,46 @@
+The compositor is the box of tricks inside the window manager which performs
+special effects on the windows on your screen. Metacity's compositor is
+under development. Your help is requested in finding and fixing bugs. This
+document tells you how to configure Metacity so that you can use compositing.
+
+To turn the compositor on initially, you need to pass --enable-compositor to
+the configure script. This will introduce a dependence on libcm, which you
+can get from <URL:http://ftp.gnome.org/pub/GNOME/sources/libcm/>.
+
+When Metacity is compiled, you will need to turn the compositor on in gconf
+for it to have any effect. You will find the boolean switch at
+
+   /apps/metacity/general/compositing_manager
+
+When that's done, you can set some environment variables before you launch
+Metacity to influence how the compositor works. These will eventually become
+configuration options or gconf options when they grow up. Define them to any
+value to turn them on; leave them undefined to turn them off. Currently the
+options you can set are:
+
+   LIBCM_DIRECT
+
+      If this is set, the compositor will bypass the X server and do all its
+      work directly with the hardware. I know of no reason you would want to
+      do so, but perhaps you do.
+
+   LIBCM_TFP
+
+      If this is set ("tfp mode"), the compositor will feel free to use the
+      texture_from_pixmap extension; if this is not set ("non-tfp mode"), the
+      compositor will use a workaround. Many drivers require non-tfp mode in
+      order to work, and will paint all windows clear blue or clear white
+      without it. Thanks to Travis Watkins for suggesting this switch; he
+      cautions that some games or video players may require tfp mode.
+
+   METACITY_BLING
+
+      This turns on several pretty but non-essential animations (dialogues
+      fracturing and exploding, minimisations doing a shrinkydink effect,
+      and so on). If it is not set, the standard non-GL animations are
+      retained. This affects only window event animations; it doesn't change
+      menus zooming, dialogues being semi-transparent, and so on. Try it
+      and see whether you like it.
+
+If you have any problems, ask on metacity-devel-list@gnome.org, or
+#gnome-hackers on gimpnet, or come and find me (tthurman at gnome) and ask.

doc/how-constraints-works.txt

@@ -0,0 +1,283 @@
+File contents:
+  Basic Ideas
+  Important points to remember
+  Explanation of fields in the ConstraintInfo struct
+  Gory details of resize_gravity vs. fixed_directions
+
+IMPORTANT NOTE: There's a big comment at the top of constraints.c
+explaining how to add extra constraints or tweak others.  Read it.  I put
+that information there because it may be enough information by itself for
+people to hack on constraints.c.  I won't duplicate that information in
+this file; this file is for deeper details.
+
+
+---------------------------------------------------------------------------
+Basic Ideas
+---------------------------------------------------------------------------
+There are a couple basic ideas behind how this constraints.c code works and
+why it works that way:
+
+  1) Split the low-level error-prone operations into a special file
+  2) Add robustness by prioritizing constraints
+  3) Make use of a minimal spanning set of rectangles for the
+     "onscreen region" (screen minus struts).
+  4) Constraints can be user-action vs app-action oriented
+  5) Avoid over-complification  ;-)
+
+Some more details explaining these basic ideas:
+
+  1) Split tedious operations out
+
+     boxes.[ch] have been added which contain many common, tedious, and
+     error-prone operations.  I find that this separation helps a lot for
+     managing the complexity and ensuring that things work correctly.
+     Also, note that testboxes.c thoroughly tests all functionality in
+     boxes.[ch] and a testboxes program is automatically compiled.
+
+     Note that functions have also been added to this file to handle some
+     of the tedium necessary for edge resistance as well.
+
+  2) Prioritize constraints
+
+     In the old code, if each and every constraint could not be
+     simultaneously satisfied, then it would result in some
+     difficult-to-predict set of constraints being violated.  This was
+     because constraints were applied in order, with the possibility for
+     each making changes that violated previous constraints, with no
+     checking done at the end.
+
+     Now, all constraints have an associated priority, defined in the
+     ConstraintPriority enum near the top of constraints.c.  The
+     constraints are all applied, and then are all checked; if not all are
+     satisfied then the least important constraints are dropped and the
+     process is repeated.  This ensures that the most important constraints
+     are satisfied.
+
+     A special note to make here is that if any one given constraint is
+     impossible to satisfy even individually (e.g. if minimum size hints
+     specify a larger window than the screen size, making the
+     fully-onscreen constraint impossible to satisfy) then we treat the
+     constraint as being satisfied.  This sounds counter-intuitive, but the
+     idea is that we want to satisfy as many constraints as possible and if
+     we treat it as a violation then all constraints with a lesser priority
+     also get dropped along with the impossible to satisfy one.
+
+  3) Using maximal/spanning rectangles
+
+     The constraints rely heavily on something I call spanning rectangles
+     (which Soeren referred to as maximal rectangles, a name which I think
+     I like better but I don't want to go change all the code now).  These
+     spanning rectangles have the property that a window will fit on the
+     screen if and only if it fits within at least one of the rectangles.
+     Soeren had an alternative way of describing these rectangles, namely
+     that they were rectangles with the property that if you made any of
+     them larger in any direction, they would overlap with struts or be
+     offscreen (with the implicit assumption that there are enough of these
+     rectangles that combined they cover all relevant parts of the screen).
+     Note that, by necessity, these spanning/maximal rectangles will often
+     overlap each other.
+
+     Such a list makes it relatively easy to define operations like
+     window-is-onscreen or clamp-window-to-region or
+     shove-window-into-region.  Since we have a on-single-xinerama
+     constraint in addition to the onscreen constraint(s), we cache
+     number_xineramas + 1 of these lists in the workspace.  These lists
+     then only need to be updated whenever the workarea is (e.g. when strut
+     list change or screen or xinerama size changes).
+
+  4) Constraints can be user-action vs app-action oriented
+
+     Such differentiation requires special care for the constraints to be
+     consistent; e.g. if the user does something and one constraint
+     applies, then the app does something you have to be careful that the
+     constraint on the app action doesn't result in some jarring motion.
+
+     In particular, the constraints currently allow offscreen movement or
+     resizing for user actions only.  The way consistency is handled is
+     that at the end of the constraints, update_onscreen_requirements()
+     checks to see if the window is offscreen or split across xineramas and
+     updates window->require_fully_onscreen and
+     window->require_on_single_xinerama appropriately.
+
+  5) Avoid over-complification
+
+     The previous code tried to reform the constraints into terms of a
+     single variable.  This made the code rather difficult to
+     understand. ("This is a rather complicated fix for an obscure bug
+     that happened when resizing a window and encountering a constraint
+     such as the top edge of the screen.")  It also failed, even on the
+     very example for which it used as justification for the complexity
+     (bug 312104 -- when keyboard resizing the top of the window,
+     Metacity extends the bottom once the titlebar hits the top panel),
+     though the reason why it failed is somewhat mysterious as it should
+     have worked.  Further, it didn't really reform the constraints in
+     terms of a single variable -- there was both an x_move_delta and an
+     x_resize_delta, and the existence of both caused bug 109553
+     (gravity with simultaneous move and resize doesn't work)
+
+
+---------------------------------------------------------------------------
+Important points to remember
+---------------------------------------------------------------------------
+
+  - Inner vs Outer window
+
+    Note that because of how configure requests work and
+    meta_window_move_resize_internal() and friends are set up, that the
+    rectangles passed to meta_window_constrain() are with respect to inner
+    window positions instead of outer window positions (meaning that window
+    manager decorations are not included in the position/size).  For the
+    constraints that need to be enforced with respect to outer window
+    positions, you'll need to make use of the extend_by_frame() and
+    unextend_by_frame() functions.
+
+  - meta_window_move_resize_internal() accepts a really hairy set of
+    inputs.  See the huge comment at the beginning of that function.
+    constraints gets screwed up if that function can't sanitize the input,
+    so be very careful about that.  It used to be pretty busted.
+
+
+---------------------------------------------------------------------------
+Explanation of fields in the ConstraintInfo strut
+---------------------------------------------------------------------------
+
+As of the time of this writing, ConstraintInfo had the following fields:
+  orig
+  current
+  fgeom
+  action_type
+  is_user_action
+  resize_gravity
+  fixed_directions
+  work_area_xinerama
+  entire_xinerama
+  usable_screen_region
+  usable_xinerama_region
+
+A brief description of each and/or pointers to more information are found
+below:
+  orig
+    The previous position and size of the window, ignoring any window
+    decorations
+  current
+    The requested position and size of the window, ignoring any window
+    decorations.  This rectangle gets modified by the various constraints
+    to specify the allowed position closest to the requested position.
+  fgeom
+    The geometry of the window frame (i.e. "decorations"), if it exists.
+    Otherwise, it's a dummy 0-size frame for convenience (i.e. this pointer
+    is guaranteed to be non-NULL so you don't have to do the stupid check).
+  action_type
+    Whether the action being constrained is a move, resize, or a combined
+    move and resize.  Some constraints can run faster with this information
+    (e.g. constraining size increment hints or min size hints don't need to
+    do anything for pure move operations).  This may also be used for
+    providing slightly different behavior (e.g. clip-to-region instead of
+    shove-into-region for resize vs. moving operations), but doesn't
+    currently have a lot of use for this.
+  is_user_action
+    Used to determine whether the action being constrained is a user
+    action.  If so, certain parts of the constraint may be relaxed.  Note
+    that this requires care to get right; see item 4 of the basic ideas
+    section for more details.
+  resize_gravity
+    The gravity used in the resize operation, used in order to make sure
+    windows are resized correctly if constraints specify that their size
+    must be modified.  Explained further in the resize_gravity
+    vs. fixed_directions section.
+  fixed_directions
+    There may be multiple solutions to shoving a window back onscreen.
+    Typically, the shortest distance used is the solution picked, but if
+    e.g. an application only moved its window in a single direction, it's
+    more desirable that the window is shoved back in that direction than in
+    a different one.  fixed_directions facilitates that.  Explained further
+    in the resize_gravity vs. fixed_directions section.
+  work_area_xinerama
+    This region is defined in the workspace and just cached here for
+    convenience.  It is basically the area obtained by taking the current
+    xinerama, treating all partial struts as full struts, and then
+    subtracting all struts from the current xinerama region.  Useful
+    e.g. for enforcing maximization constraints.
+  entire_xinerama
+    Just a cache of the rectangle corresponding to the entire current
+    xinerama, including struts.  Useful e.g. for enforcing fullscreen
+    constraints.
+  usable_screen_region
+    The set of maximal/spanning rectangles for the entire screen; this
+    region doesn't overlap with any struts and helps to enforce
+    e.g. onscreen constraints.
+  usable_xinerama_region
+    The set of maximal/spanning rectangles for the current xinerama; this
+    region doesn't overlap with any struts on the xinerama and helps to
+    enforce e.g. the on-single-xinerama constraint.
+
+
+---------------------------------------------------------------------------
+Gory details of resize_gravity vs. fixed_directions
+---------------------------------------------------------------------------
+
+Note that although resize_gravity and fixed_directions look similar, they
+are used for different purposes:
+
+  - resize_gravity is only for resize operations and is used for
+    constraints unrelated to keeping a window within a certain region
+  - fixed_directions is for both move and resize operations and is
+    specifically for keeping a window within a specified region.
+
+Examples of where each are used:
+
+  - If a window is simultaneously moved and resized to the southeast corner
+    with SouthEastGravity, but it turns out that the window was sized to
+    something smaller than the minimum size hint, then the size_hints
+    constraint should resize the window using the resize_gravity to ensure
+    that the southeast corner doesn't move.
+  - If an application resizes itself so that it grows downward only (which
+    I note could be using any of three different gravities, most likely
+    NorthWest), and happens to put the southeast part of the window under a
+    partial strut, then the window needs to be forced back on screen.
+    (Yes, shoved onscreen and not clipped; see bug 136307).  It may be the
+    case that moving the window to the left results in less movement of the
+    window than moving the window up, which, in the absence of fixed
+    directions would cause us to chose moving to the left.  But since the
+    user knows that only the height of the window is changing, they would
+    find moving to the left weird (especially if this were a dialog that
+    had been centered on its parent).  It'd be better to shove the window
+    upwards so we make sure to keep the left and right sides fixed in this
+    case.  Note that moving the window upwards (or leftwards) is probably
+    totally against the gravity in this case; but that's okay because
+    gravity typically assumes there's more than enough onscreen space for
+    the resize and we only override the gravity when that assumption is
+    wrong.
+
+For the paranoid, a fixed directions might give an impossible to fulfill
+constraint (I don't think that's true currently in the code, but I haven't
+thought it through in a while).  If this ever becomes a problem, it should
+be relatively simple to throw out the fixed directions when this happens
+and rerun the constraint.  Of course, it might be better to rethink things
+to just avoid such a problem.
+
+The nitty gritty of what gets fixed:
+  User move:
+    in x direction - y direction fixed
+    in y direction - x direction fixed
+    in both dirs.  - neither direction fixed
+  User resize: (note that for clipping, only 1 side ever changed)
+    in x direction - y direction fixed (technically opposite x side fixed too)
+    in y direction - x direction fixed (technically opposite y side fixed too)
+    in both dirs.  - neither direction fixed
+  App move:
+    in x direction - y direction fixed
+    in y direction - x direction fixed
+    in both dirs.  - neither direction fixed
+  App resize
+    in x direction - y direction fixed
+    in y direction - x direction fixed
+    in 2 parallel directions (center side gravity) - other dir. fixed
+    in 2 orthogonal directions (corner gravity) - neither dir. fixed
+    in 3 or 4 directions (a center-like gravity) - neither dir. fixed
+  Move & resize
+    Treat like resize case though this will usually mean all four sides
+    change and result in neither direction being fixed
+  Note that in all cases, if neither direction moves it is likely do to a
+  change in struts and thus neither direction should be fixed despite the
+  lack of movement.

doc/how-to-get-focus-right.txt

@@ -9,7 +9,8 @@ basics are easy:
 Focus method  Behavior
     click     When a user clicks on a window, focus it
    sloppy     When an EnterNotify is received, focus the window
-    mouse     Same as sloppy, but also defocus on LeaveNotify
+    mouse     Same as sloppy, but also defocus when mouse enters DESKTOP
+              window
 
 Note that these choices (along with the choice that clicking on a
 window raises it for the click focus method) introduces the following
@@ -20,8 +21,8 @@ Focus method  Invariant
    sloppy     If the mouse is in a window, then it is focused; if the
               mouse is not in a window, then the most recently used
               window is focused.
-    mouse     If the mouse is in a window, then it is focused; otherwise,
-              the designated "no_focus_window" is focused
+    mouse     If the mouse is in a non-DESKTOP window, then it is focused;
+              otherwise, the designated "no_focus_window" is focused
 
 However, there are a number of cases where the current focus window
 becomes invalid and another should be chosen.  Some examples are when
@@ -34,8 +35,17 @@ Focus method  Behavior
               on top)
    sloppy     Focus the window containing the pointer if there is such
               a window, otherwise focus the most recently used window.
-    mouse     Focus the window containing the pointer if there is one,
-              otherwise focus the designated "no_focus_window".
+    mouse     Focus the non-DESKTOP window containing the pointer if
+              there is one, otherwise focus the designated
+              "no_focus_window".
+
+Note that "most recently used window", as used here, has a slightly
+different connotation than "most recent to have keyboard focus".  This
+is because when a user activates a window that is a transient, its
+ancestor(s) should be considered to be more recently used than other
+windows that have had the keyboard focus more recently.  (See bug
+157360; this may mean that the alt-tab order should also change
+simultaneously, although the current implementation does not do that.)
 
 Also, sometimes a new window will be mapped (e.g. unminimizing a
 window or launching a new application).  Most users want to interact
@@ -54,9 +64,9 @@ cases in which a new window shouldn't be focused:
 
 To handle these cases, Metacity compares timestamps of the event that
 caused the launch and the timestamp of the last interaction with the
-focused window.  (Case 2 is handled by providing a special timestamp
-of 0 for the launch time, which ensures that the window that appears
-doesn't get focus)
+focused window.  (Case 2 is handled by the application providing a
+special timestamp of 0 for the launch time, which ensures that the
+window that appears doesn't get focus)
 
 If the newly launched window isn't focused, some things should be done
 to alert the user that there is a window to work with:
@@ -71,17 +81,35 @@ to alert the user that there is a window to work with:
 Additionally, the user may decide to use the keyboard instead of the mouse
 to navigate between windows (referred to as "keynav").  This poses no
 problems for click-to-focus (because the same invariant can be
-maintained), but for sloppy and mouse focus it means that EnterNotify
-and LeaveNotify events should be ignored (they can be generated
-without using the mouse, for example, by grabs).
+maintained), but for sloppy and mouse focus it requires extra work to
+attempt to handle the INHERENTLY CONFLICTING CONSTRAINTS.  Metacity does
+this by having a mouse_mode boolean used to determine which of the two
+sets of invariants holds.  This mode is set according to which method was
+most recently used to choose a focus window:
+  1) When receiving EnterNotify events from mouse movement, set
+     mouse_mode to TRUE.
+  2) When using keynav to choose a focus window (e.g. alt-tab, alt-esc,
+     alt-f2, move-window-to-workspace keybindings), set mouse_mode to FALSE.
+  3) When handling events that don't choose a focus window but rather need
+     a focus_window chosen for them (e.g. switch-to-workspace keybindings),
+     don't change the mouse_mode and just use the current value.
+Note that grabs present a special case since they can generate EnterNotify
+and LeaveNotify events without using the mouse, thus these events should be
+ignored when the crossing mode is NotifyGrab or NotifyUngrab.  THIS
+MOUSENAV/KEYNAV MODERATION METHOD IS NOT PERFECT--there are corner cases
+when trying to mix-and-match between mousenav and keynav simultaneously
+that cause problems; but it appears to be the most reasonable tradeoff and
+works well in most cases, especially if the user sticks to just mousenav
+for a long time or just keynav for a long time.
 
 Finally, windows of type WM_DOCK or WM_DESKTOP (e.g. the desktop and
-the panel) present a special case.  For all focus modes, we only focus
-these windows if the user clicks on them or uses Ctrl-Alt-Tab to
-navigate to them.  (Well, erm, actually they can be focused in click
-and sloppy focus modes if no other window besides these are found, but
-there shouldn't be any difference in behavior between doing this and
-focusing the designated "no_focus_window")
+the panel) present a special case, at least partially due to the lack
+of decorations.  For WM_DESKTOP windows, we only focus them if the
+user explicitly requests it (e.g. clicks on the window, uses
+Ctrl-Alt-Tab to navigate to it, uses a keybinding to show the desktop,
+etc.).  For WM_DOCK windows, we do not focus unless we receive a very
+explicit request (e.g. Ctrl-Alt-Tab or a _NET_ACTIVE_WINDOW message;
+not normal clicks).
 
 
 
@@ -94,10 +122,13 @@ To read more about the bugs that inspired these choices:
     Also, the EWMH spec, especially the parts relating to _NET_WM_USER_TIME
   - Modal vs. non-modal dialogs that get denied focus when mapped
     http://bugzilla.gnome.org/show_bug.cgi?id=151996
-  - Ignoring EnterNotify and LeaveNotify events during keynav
+  - Mousenav vs. Keynav in mouse and sloppy focus modes
+    http://bugzilla.gnome.org/show_bug.cgi?id=167545
     http://bugzilla.gnome.org/show_bug.cgi?id=101190
+    http://bugzilla.gnome.org/show_bug.cgi?id=357695
   - Not focusing panels
-    http://bugzilla.gnome.org/show_bug.cgi?id=120100 (maybe a different bug?)
+    http://bugzilla.gnome.org/show_bug.cgi?id=160470
+    http://bugzilla.gnome.org/show_bug.cgi?id=120100
 
 There were many bugs which had to be fixed to get all the above
 working; they helped form these policies and/or show the difficulties
@@ -111,6 +142,7 @@ the ones I'm the most familiar with):
   bug  95747  should ignore EnterNotify events with NotifyInferior detail set
   bug  97635  sticky windows always keep focus when switching workspaces
   bug 102665  a window unminimized from the tasklist should be focused
+  bug 107347  focus windows that manually position themselves too
   bug 108643  focus in MRU order instead of stack order
   bug 110970  moving a window to another workspace loses focus
   bug 112031  closing a dialog can result in a strange focus window
@@ -118,6 +150,7 @@ the ones I'm the most familiar with):
   bug 120100  panel shouldn't be focused after workspace applet usage
   bug 123803  need final EnterNotify after workspace switch (see also 124798)
   bug 124981  focus clicked window in pager only if on current workspace
+  bug 125492  catch the xserver unfocusing everything and fix its braindeadedness
   bug 128200  focus correct window on libwnck window minimize (see 107681 too)
   bug 131582  fix race condition on window minimize/close
   bug 133120  wrong window focused when changing workspaces
@@ -138,6 +171,18 @@ the ones I'm the most familiar with):
   bug 151990  prevent focus inconsistencies by only providing one focus method
   bug 151996  modal dialogs denied focus should not be lowered
   bug 152000  fix race on window close followed by rapid mouse movement
+  bug 152004  ways to handle new window versus mouse invariants
+  bug 153220  catch the root window getting focus and reset to default window
+  bug 157360  focus parents of dismissed transient windows in preference to
+              the window that most recently had focus
+  bug 159257  focus the desktop when showing it
+  bug 160470  don't focus panels on click
+  bug 163450  correct highlighting in workspace switcher popup
+  bug 164716  refuse to focus a window with a modal transient, and focus
+              the transient instead
+  bug 166524  avoid new windows being obscured by the focus window
+  bug 167545  mousenav vs. keynav in mouse and sloppy focus modes
+  <a massive heap of bugs relating to focus stealing prevention...>
 
 
 Addendum on sloppy and mouse focus
@@ -146,7 +191,7 @@ Addendum on sloppy and mouse focus
 
   1) Keynav doesn't maintain the same invariants as mouse navigation
      for these focus modes; switching back and forth between
-     navigation methods, therefore, may appear to have
+     navigation methods, therefore, may have or appear to have
      inconsistencies.  Examples:
      a) If the user uses Alt-Tab to change the window with focus, then
         starts to move the mouse, at that moment the window where the
@@ -172,6 +217,15 @@ Addendum on sloppy and mouse focus
         containing the menu) but is one of those hard-to-get-right
         keynav and mouse focus mixture cases.  (See bug 101190 for
         more details)
+     d) Similar to (c), moving the mouse off the menu doesn't immediately
+        focus the window that the mouse goes over, due to an application
+        grab (we couldn't change this and wouldn't want to, but
+        technically it does break the invariant).
+     e) If mouse_mode is off and the user does something to cause focus to
+        change (e.g. switch workspaces, close or minimize a window, etc.)
+        and simultaneously tries to move the mouse, the choice of which
+        window to focus is inherently race-y.  (You probably can't satisfy
+        both keynav and mousenav invariants simultaneously...)
   2) The sloppy/mouse invariants are often not strictly maintained;
      for example, we provide an exception to the invariant for newly
      mapped windows.  (Most find that not allowing this exception is

doc/man/.cvsignore

@@ -0,0 +1,2 @@
+Makefile
+Makefile.in

doc/man/Makefile.am

@@ -0,0 +1,3 @@
+man_MANS = metacity.1 metacity-theme-viewer.1 metacity-window-demo.1
+
+EXTRA_DIST = $(man_MANS)

doc/man/metacity-theme-viewer.1

@@ -0,0 +1,43 @@
+.\" In .TH, FOO should be all caps, SECTION should be 1-8, maybe w/ subsection
+.\" other parms are allowed: see man(7), man(1)
+.\"
+.\" Based on template provided by Tom Christiansen <tchrist@jhereg.perl.com>.
+.\" 
+.TH METACITY-THEME-VIEWER 1 "1 June 2004" 
+.SH NAME
+metacity-theme-viewer \- view metacity themes
+.SH SYNOPSIS
+.B metacity-theme-viewer
+[
+.I THEMENAME
+]
+.SH DESCRIPTION
+.\" Putting a newline after each sentence can generate better output.
+.B metacity-theme-viewer
+allows you to preview any installed Metacity theme.
+.PP
+When designing a new Metacity theme, you can use
+.B metacity-theme-viewer
+to measure the performance of a window frame option, and to preview
+the option.
+.SH OPTIONS
+.TP
+.I THEMENAME
+Name of the theme to be shown (\fIAtlanta\fR by default).
+It is case-sensitive.
+.SH FILES
+.br
+.nf
+.TP
+.I /usr/share/themes
+system themes directory
+.TP
+.I /usr/share/themes/*/metacity-1/metacity-theme-1.xml
+theme specification file
+.SH AUTHOR
+This manual page was written by Jose M. Moya <josem@die.upm.es>, for
+the Debian  GNU/Linux system (but may be used by others).
+.SH "SEE ALSO"
+.\" Always quote multiple words for .SH
+.BR metacity (1),
+.BR metacity-window-demo (1).

doc/man/metacity-window-demo.1

@@ -0,0 +1,25 @@
+.\" In .TH, FOO should be all caps, SECTION should be 1-8, maybe w/ subsection
+.\" other parms are allowed: see man(7), man(1)
+.\"
+.\" Based on template provided by Tom Christiansen <tchrist@jhereg.perl.com>.
+.\" 
+.TH METACITY-WINDOW-DEMO 1 "1 June 2004" 
+.SH NAME
+metacity-window-demo \- demo of window features
+.SH SYNOPSIS
+.B metacity-window-demo
+.SH DESCRIPTION
+.\" Putting a newline after each sentence can generate better output.
+This program demonstrates various kinds of windows that window
+managers and window manager themes should handle.
+.PP
+Be sure to tear off the menu and toolbar, those are also a special
+kind of window.
+.SH AUTHOR
+This manual page was written by Jose M. Moya <josem@die.upm.es>, for
+the Debian  GNU/Linux system (but may be used by others).
+.SH "SEE ALSO"
+.\" Always quote multiple words for .SH
+.BR x-window-manager (1),
+.BR metacity (1),
+.BR metacity-theme-viewer (1).

doc/man/metacity.1

@@ -0,0 +1,60 @@
+.\"                                      Hey, EMACS: -*- nroff -*-
+.\" First parameter, NAME, should be all caps
+.\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
+.\" other parameters are allowed: see man(7), man(1)
+.TH METACITY 1 "11 February 2006"
+.\" Please adjust this date whenever revising the manpage.
+.\"
+.\" Some roff macros, for reference:
+.\" .nh        disable hyphenation
+.\" .hy        enable hyphenation
+.\" .ad l      left justify
+.\" .ad b      justify to both left and right margins
+.\" .nf        disable filling
+.\" .fi        enable filling
+.\" .br        insert line break
+.\" .sp <n>    insert n+1 empty lines
+.\" for manpage-specific macros, see man(7)
+.SH NAME
+METACITY \- minimal GTK2 Window Manager
+.SH SYNOPSIS
+.B metacity
+[\-\-display=\fIDISPLAY\fP] [\-\-replace] [\-\-sm\-client\-id=\fIID\fP] [\-\-sm\-disable] [\-\-sm\-save\-file=\fIFILENAME\fP] [\-\-version] [\-\-help]
+.SH DESCRIPTION
+This manual page documents briefly
+.B metacity\fP.
+.PP
+.\" TeX users may be more comfortable with the \fB<whatever>\fP and
+.\" \fI<whatever>\fP escape sequences to invode bold face and italics, 
+.\" respectively.
+\fBmetacity\fP is a minimal X window manager aimed at nontechnical users and is designed to integrate well with the GNOME desktop.  \fBmetacity\fP lacks some features that may be expected by traditional UNIX or other technical users; these users may want to investigate other available window managers for use with GNOME or standalone.
+.SH OPTIONS
+.TP
+.B \-\-display=DISPLAY
+Connect to X display \fIDISPLAY\fP.
+.TP
+.B \-\-replace
+a window manager which is running is replaced by \fBmetacity\fP.  Users are encouraged to change the GNOME window manager by running the new WM with the --replace or -replace option, and subsequently saving the session.
+.TP
+.B \-\-sm\-client\-id=ID
+Specify a session management \fIID\fP.
+.TP
+.B \-\-sm\-disable
+Disable the session management.
+.TP
+.B \-\-sm\-save\-file=FILENAME
+Load a session from \fIFILENAME\fP.
+.TP
+.B \-\-version
+Print the version number.
+.TP
+.B \-?, \-\-help
+Show summary of options.
+.SH CONFIGURATION
+\fBmetacity\fP configuration can be found under \fIPreferences\fP->\fIWindows\fP and \fIPreferences\fP->\fIKeyboard Shortcuts\fP on the menu-panel. Advanced configuration can be achieved directly through gconf editing (gconf-editor or gconftool-2).
+.SH SEE ALSO
+.BR metacity-message (1)
+.SH AUTHOR
+The original manual page was written by Thom May <thom@debian.org>.  It was updated by Akira TAGOH <tagoh@debian.org>
+for the Debian GNU/Linux system (with permission to use by others), and then updated by Luke Morton and Philip O'Brien
+for inclusion in metacity.

doc/strut-and-related-updating.txt

@@ -0,0 +1,54 @@
+How updates happen for struts, workareas, and screen/xinerama regions/edges:
+  One of three things causes meta_window_update_struts to be called
+    (a) initial window map (window.c:meta_window_new_with_attrs())
+    (b) update of _net_wm_strut* properties (window.c:process_property_notify())
+    (c) screen resizes (e.g. via xrandr; from screen.c:meta_screen_resize_func())
+  meta_window_update_struts (MetaWindow *window)
+    - Gets new list of struts from window properties
+    - Makes sure window doesn't single-handedly fill the screen
+    - records new struts if different and calls invalidate_work_areas()
+  invalidate_work_areas ()
+    - Calls meta_workspace_invalidate_work_area() for each workspace it's on
+  meta_workspace_invalidate_work_area()
+    - Cleans out all strut lists
+    - queues all windows for resizing
+    - Calls meta_screen_queue_workarea_recalc (workspace->screen);
+  meta_screen_queue_workarea_recalc()
+    - Adds set_work_area_idle_func() as an idle handler
+
+  set_work_area_idle_func()
+    - Calls set_work_area_hint()
+  set_work_area_hint()
+    - Calls meta_workspace_get_work_area_all_xineramas()
+    - Sets _NET_WORKAREA property
+  meta_workspace_get_work_area_all_xineramas()
+    - Calls ensure_work_areas_validated()
+  ensure_work_areas_validated()
+    - Loops over xineramas
+      - Loops over windows, then struts:
+        - Adds struts to list first time through xinerama loop
+        - Find the amount of the strut on the given xinerama for <dir>_strut
+        - Just max the amount of the strut with the all_<dir>_strut
+      - Makes sure there's a non-empty xinerama workarea
+      - Record the xinerama workarea
+    - Make sure there's a non-empty screen workarea
+    - Record the screen workarea
+    - Cache the spanning rects for the screen and xinerama regions
+    - Cache the screen and xinerama edges
+
+  Alternatively to all the above, if the idle function for the screen
+  has not yet fired, constraints.c:setup_constraint_info() can call
+  either workspace.c:meta_workspace_get_onscreen_region() or
+  workspace.c:meta_workspace_get_onxinerama_region() which in turn
+  call workspace.c:ensure_work_areas_validated().
+
+Meaning of related functions that might be difficult to tell apart:
+  screen.c:meta_screen_get_current_xinerama ()
+    - Finds out which xinerama the mouse is on with an XQueryPointer
+  window.c:meta_window_get_work_area_current_xinerama()
+  window.c:meta_window_get_work_area_for_xinerama()
+  window.c:meta_window_get_work_area_all_xineramas ()
+    - All three are for finding the intersection of workareas across
+      multiple workspaces so that placement of windows can be
+      determined in such a way that they remain in the workarea for
+      all workspaces that they are on.

doc/theme-format.txt

@@ -1,6 +1,91 @@
-Docs on the theme format
+Themes are in a simple XML-subset format. There are multiple versions
+of the theme format, and a given theme can support more than one format.
 
-Themes are in a simple XML-subset format.
+Version 1:     THEMEDIR/metacity-1/metacity-theme-1.xml
+  (original metacity format)
+Version 2:     THEMEDIR/metacity-1/metacity-theme-2.xml
+
+The subdirectory name is "metacity-1" in all versions.
+
+As you might expect, older versions of metacity will not understand
+newer theme formats. However, newer versions will use old themes.
+Metacity will always use the newest theme format it understands that
+the X server supports. Some format versions are only supported if you
+have the right X server features.
+
+Each format *requires* the corresponding filename. If you put version
+2 format features in the metacity-1/metacity-theme-1.xml file, then
+metacity will get angry.
+
+This document has separate sections for each format version. You may
+want to read the document in reverse order, since the base features
+are discussed under version 1.
+
+New Features in Theme Format Version 2
+======================================
+
+The optional attributes rounded_top_left, rounded_top_right,
+rounded_bottom_left and rounded_bottom_right on <frame_geometry>
+should now be the radius of the corner in pixels. You may still use
+the values "false" for 0 and "true" for 5, which means v1 values will
+still work just fine.
+
+<frame_geometry> has a new optional attribute, hide_buttons. If this
+is true, no buttons will be displayed on the titlebar.
+
+Anywhere you can use a positive integer, you can use an integer constant.
+
+As well as constant integers and reals, you may define constant colours,
+thus:
+  <constant name="RevoltingPink" value="#FF00FF"/>
+  <constant name="Background" value="gtk:bg[NORMAL]"/>
+
+<frame_style> has two new optional attributes, background and alpha.
+If you specify alpha, you must specify background. background is a
+colour used for the background of the frame. alpha is the transparency
+as a real between 0.0 and 1.0. If the current X server does not support
+alpha channels, the value is ignored.
+
+The filename attribute of <image> may begin with "theme:". If so, the
+rest of the string is the name of a theme icon. The 64x64 version of the
+icon is used, except for fallback mini_icons, which use the 16x16 version.
+This does not affect ordinary resizing. For example:
+  <button function="close" state="normal">
+    <draw_ops>
+      <include name="active_button"/>
+      <image filename="theme:gnome-logout" x="2" y="2"
+          width="width-4" height="height-4"/>
+      <!-- Note: not "theme:gnome-logout.png" or similar. -->
+    </draw_ops>
+  </button>
+
+<menu_icon>s are parsed but ignored.
+
+Fallback icons can be specified using <fallback>. There are two
+optional arguments, icon and mini_icon. The values of these arguments
+are identical to that of the filename attribute of <image>. Fallback
+icons are used when a window does not supply its own icon. If a fallback
+icon is not specified with <fallback>, Metacity will use a built-in
+icon, as in metacity-theme-1.
+
+The <arc> element, as well as the original start_angle and end_angle
+attributes, may be given from and to attributes. The values of these
+attributes are given in degrees clockwise, with 0 being straight up.
+For example:
+  <arc from="0.0" to="90.0" filled="true" color="#FF00FF"
+      x="0" y="5" width="15" height="15"/>
+
+<frame state="shaded"> may now take an optional resize attribute, with
+the same interpretation as the resize attribute on <frame state="normal">.
+If this attribute is omitted for state="shaded", it defaults to "both".
+(If it is omitted for state="normal", it remains an error.)
+
+In addition to the four <button> functions which are required in
+metacity-theme-1, there are six new functions in metacity-theme-2:
+shade, unshade, above, unabove, stick and unstick.
+      
+Overview of Theme Format Version 1
+==================================
 
 <?xml version="1.0"?>
 <metacity_theme>

po/.cvsignore

@@ -9,3 +9,4 @@ cat-id-tbl.c
 messages
 missing
 stamp-cat-id
+stamp-it

po/LINGUAS

@@ -0,0 +1,78 @@
+# please keep this list sorted alphabetically
+#
+am
+ar
+az
+be
+be@latin
+bg
+bn
+bn_IN
+bs
+ca
+cs
+cy
+da
+de
+dz
+el
+en_CA
+en_GB
+es
+et
+eu
+fa
+fi
+fr
+ga
+gl
+gu
+he
+hi
+hr
+hu
+hy
+id
+is
+it
+ja
+ka
+ko
+ku
+lt
+lv
+mg
+mk
+ml
+mn
+mr
+ms
+nb
+ne
+nl
+nn
+or
+pa
+pl
+pt
+pt_BR
+ro
+ru
+rw
+sk
+sl
+sq
+sr
+sr@Latn
+sv
+ta
+th
+tk
+tr
+uk
+vi
+wa
+xh
+zh_CN
+zh_HK
+zh_TW

po/POTFILES.in

@@ -19,8 +19,6 @@ src/session.c
 src/theme-parser.c
 src/theme-viewer.c
 src/theme.c
-src/tools/metacity-properties.desktop.in
-src/tools/metacity-properties.glade
 src/util.c
 src/window-props.c
 src/window.c