root / README.parti

FAQ for the Parti window manager
================================

What is Parti?
--------------

Parti is a tabbing/tiling (one might say "partitioning") window
manager.  Its goal is to bring this superior window management
interface to modern, mainstream desktop environments.  It is written
in Python, uses GTK+, has an automated test suite, and is released
under the GPL.


Could you say that again, slower?  There are like seven thousand
window managers out there.  What makes Parti special?
----------------------------------------------------------------

Parti is a window manager (WM), i.e., it is a program that provides an
interface for arranging and switching between all the other programs
you run on your computer.  People generally use exactly one WM at a
time, like KWin or Metacity or, now, Parti.

There are lots of WMs like KWin or Metacity or Compiz that focus on
integrating cleanly with modern Unix desktops, and looking good while
doing it.  These WMs all use the traditional "desktop" metaphor where
applications are like sheets of paper that you can put anywhere you
want and in whatever arrangement makes sense to you.  The problem with
this is that my real-world desk is a total mess, and the windows on my
computer desktop are not much better.  Until they invent
self-organizing paper, my real-world desktop is a lost cause, but my
computer desktop doesn't have to be.  Those gigahertz in there could
be doing all sorts of things to help me keep track of windows and
arrange them for me.

There are also lots of lesser-known WMs like ion or wmii that focus on
providing exactly this kind of assistance, by helping you pick from a
few good layouts (tiled, or tabbed, or one window full-screen, etc.),
and automatically keeping windows arranged for you.  The result is
vastly more usable, because you stop having to screw around arranging
windows by hand, the resulting arrangements are actually better, and
more powerful keyboard control becomes possible.  The problem with
these is that they're visually ugly, their desktop integration is
poor, and their acceptance by the mainstream community is nil.

So Parti attempts to bring the usability of tabbing/tiling WMs to
modern desktop environments, and serve as a test-bed where people can
try out new ideas for how the computer can help us keep track of our
tasks and manage our attention.  To make this as easy as possible,
Parti is written in (almost) pure Python and GTK+.  The basic approach
taken by Parti is to expose client windows as a special Gtk widget, so
now if you can write a Gtk program, you can write a window manager
too.

Our development priorities are usability, hackability, and standards
compliance, in that order.  For us a usable program is one that is
unobtrusive, to the point of becoming an invisible and unnoticed
extension of the user's will.  (It's also nice if it doesn't make our
eyes hurt while it's doing that.)  For us a hackable program is one
that has as little code as possible, and what code exists is clean and
has automated tests.  For us standards compliance does not include
conforming to pointless rules that make the code more complicated
without improving user experience, but it does include defining and
submitting new standards as it becomes clearer how to improve
interaction between clients and a tiling WM.


So should I start using it?
---------------------------

Probably not, it's still really alpha.  You can help fix that, though.


How is Parti licensed?
----------------------

Copyright (C) 2007 to Nathaniel Smith <njs@pobox.com>
Released under the terms of the GNU GPL v2 or (at your option) any
later version.  See the file COPYING for details (and note in
particular the LACK OF ANY WARRANTY).


How can I try Parti?
--------------------

Running './try-parti' in the source directory will build Parti, and
start a parti session inside a Xephyr nested X server.  Currently you
may need to hit "tab" to get a client window focused, and you may find
running the "parti-repl" command interesting.

Running Parti requires at least:
   python
   xlib (including extension libraries like libXtst.so)
   pygobject
   pygtk
   dbus-python
   ipython
And an X server with support for Composite.

Developing on Parti also requires:
   pyrex
   Xephyr
   Xvfb
As well as development packages of all of the above (i.e., you need
all the C header files, which may be split out into a package whose
name ends in "-dev" or "-devel").

If you are doing development, it is recommended that you also install:
   nose
   py.test
as these will allow our test harness to give better diagnostics when
tests fail.

The ipython dependency should probably become optional (it is only
needed for the REPL support).  Patches accepted.

On Debian-based OSes, try:
  # aptitude install libx11-dev libxtst-dev libxcomposite-dev \
    libxdamage-dev python-pyrex python-gobject-dev \
    python-gtk2-dev python-dbus ipython xserver-xephyr \
    xvfb python-nose python-codespeak-lib

(If you work out a similar line for another OS, like Fedora or FreeBSD
or whatever, please send it in.)


Why GTK+?  Don't you know Qt is way better, you Gnome bigot?
------------------------------------------------------------

Yeah, Qt is pretty sweet.  Unfortunately, I did have to pick one or
the other.  I started with no experience with either API, and the
initial prototype actually used Qt; I guess I could have stuck with
that and then had to answer the same question in reverse...  I mostly
switched to GTK+, though, because the Python Qt bindings seemed to
make some evil hacks harder.  (Window managers need to muck around in
the guts of X, and getting both Python and the high-level toolkits to
play along with that means you need a few evil hacks.)

So the important thing is, Parti has no desire to be a Gnome-specific
kind of thing.  We might use some parts of Gnome where appropriate,
but really we'd like it to be a first class citizen on any desktop
environment (including the critical polish details like
auto-configuring to local expectations), and will be happy to accept
patches to that effect.

Also, because Parti aims for full ICCCM and EWMH compliance (where
possible for a primarily tiling window manager), it should mostly just
work on any EWMH-compliant desktop environment (which should be pretty
much all of them, these days).  This is just about the more subtle
integration details.


These answers are all way too temperate.  Can't you say the same
things as a rant?  It's not really a window manager without a rant.
-------------------------------------------------------------------

Well, if you insist.

These days, let's start by saying, the Unix desktop totally rocks.  We
have beautiful widgets, fantastic hardware integration, best GUI APIs
ever, highly usable and accessible apps, incredible i18n, you name it.

Except for one thing.  Our mainstream window managers suck, suck,
suck.  Fundamentally.  Suck.

What do I mean by this?  Think about it: the basic job of a window
manager is to help you manage and switch between the different tasks
you're engaged in.  That's a pretty basic and pervasive part of user
experience, and so it carries a heavy responsibility.  Modern window
managers rise to this responsibility by... ignoring it totally.  We
have startup notification and wobbly windows and the basic user
experience of TWM, with windows as boxes dropped on the screen in some
arbitrary size and position.  If you want the windows arranged
differently, then you, the human, get to reach over and slide them
around one by one.  But at least you're free to have a bunch of
overlapping partially visible windows that you can't read.

Most of the time I don't really need that freedom.  I just want to
look at one window, or at two windows, or maybe an editor and two
terminals.  These are not complicated layout problems.  I think I have
better things to do with my time than solving them by hand, myself,
every time.  Let the computer do it.  It'll do a better job, too; half
the time I end up leaving big gaps that I can see my desktop through,
and while my desktop background is very pretty, I have seen it many
times and on this tiny laptop screen there are probably better things
those pixels could be doing.

Most of the time, I don't want to do fiddly high-precision work with
the mouse just to switch to a different window.  I'm not even making
the standard old complaint about moving the hand away from the
keyboard, that's pretty quick and I can do it without looking; but
using a pointer accurately is a high-precision motor task.  It takes
careful attention and hand-eye coordination.  That's *exactly* the
kind of distraction I *don't* need when I'm trying to juggle state and
maintain flow.  So perhaps once the computer has become smart enough
to put windows into two columns, it can devote some extra cycles to
figuring out how to have a single-key command for "switch to other
column"?

It's not like I'm the first person to notice this.  Think of all the
hue and cry over tabs in web browsers.  This isn't just a geeky
preoccupation; it's gotten so my mom won't use a browser without tab
support.  Even Microsoft has figured this one out.  And then there are
the tabbed terminals, tabbed editors, tabbed chat clients, on and on.
In the app space, traditional MDI is dead, and tabbing rules the
world.

Or in other words, the app developers have universally decided that
the standard sliding-little-rectangles-around-a-big-rectangle world is
annoying, to the point that it is considered a major feature if you
implement a little private tabbed window manager so that users can
avoid dealing with their main one as much as possible.  In the mean
time, according to the usability studies, lots of users are hacking up
their work style to approximate between-app tabbed as closely as they
can, by keeping ever window maximized all the time.  So there's some
room for improvement here.

The app developers have all sorts of cool new ideas, too.  Browser
tabs that show mini progress bars and visually track whether you've
looked at the tab since it finished loading, chat windows that change
color to show what sort of activity is going on, the genius iswitchb
buffer-switching interface for Emacs.  Let's give every app this
richer experience.  Let's expose it to the desktop, and make it better
at the same time -- let's write window managers that, say, let you
maximize one window on a small laptop screen, and still get the rich
little notification cues from the apps that aren't visible.  Let's do
something *new*.

Not that the basic idea of tabbing window managers is new.  Parti owes
a huge debt to the likes of pwm, ratpoison, stumpwm, trswm, xmonad and
especially the brilliant ion and wmii.  For some reason, though, the
previous window managers exploring these ideas seem to all be written
by extreme minimalists.  They like raw Xlib and write rants about
desktop bloat, and I have nothing against that per se, but honestly I
just want NetworkManager and pleasant looking fonts *and* the ability
to switch between tasks without gnashing my teeth.

So here's the Parti line: Parti is aimed first and foremost at
usability, and for us, a usable program is one that is unobtrusive to
the point of becoming an invisible and unnoticed extension of the
user's will.  Because we can't do this without fresh blood and
experimentation, Parti is written in Python, and writing new layout
schemes is as easy packing some GTK+ widgets.  Because this is too big
a job to do on our own, we use pre-existing libraries whereever
possible.  Because we need seamless integration into the desktop, we
will reach out to other developers, to extend EWMH and existing apps
to perfect our user experience.

And our goal is nothing less than acceptance as a, or the, default
window manager for a major desktop environment.  Is that an
unreasonable goal?  Possibly, and there's a long, long way between
here and there.  But let's see how far we can get.


I'm making a window manager feature comparison table.  Is Parti fast,
dynamic, light-weight, bloat-free, modern, flexible, and/or clean?
---------------------------------------------------------------------

Probably.