Re: Tabbed windows in Mutter/Metacity

[Rui Tiago Cação Matos <tiagomatos gmail com>]

2009/7/13 Karl Lattimer <karl qdh org uk>:
> http://files.getdropbox.com/u/889043/wm-rethink1.png
>
> here is a very early sketch of an idea I've been thinking about,
> pulling influences from various obvious and some not so obvious places.

Really nice mockup!

> Tabs definitely make sense in the WM from this point of view, also
> having the WM matching and combining separate application windows into
> tabs without the application developer having to think about it would be
> awesome!

Now this, as well as the subject of this thread, I really don't agree
with. It seems people keep turning to the window manager as a panacea
for implementing tabs which is something that is in the app's domain.

I'll try to argue why. Well, to me, it's clear that there are
different classes of cases where tabs make sense, but they all require
*different* kinds of tabs. Let's see,

1. Hypertext browsers allow you to "jump" from one document to
another. It's very common and thus useful to switch between those
different documents. Furthermore, they usually keep an history of
those "jumps". This means that:
  1.a) there's an unbounded number of tabs;
  1.b) the relations between tabs are usually in a tree form, i.e. you
have a root document and then you branch to a child which might branch
to N other children, etc;
  1.c) people might want to look at more that one document at the same
time, i.e. side by side;
  1.d) documents usually have the same form. Which is not actually
true in today's web due to *applications* like Gmail and Flash sites
which scream for top level windows of their own.

2. Regular form document editors/viewers like text editors, word
processors, spreadsheets. This is the class for which Karl's mockup
works the better:
  2.a) there's an unbounded number of tabs;
  2.b) documents are not usually loaded in a tree like fashion and
thus their relation is mostly linear, even though some might be
related while others are not;
  2.c) it's useful to see documents side by side;
  2.d) documents usually have the the same form.

Apps like EOG or Gimp are a subclass of n. 2 here since they only
differ in the fact that the documents they work with can be very
different in form, i.e. squares, landscape rectangles, portrait
rectangles, etc.

3. Plain old preference dialogs are mostly well covered by today's
implementations:
  3.a) known in advance and usually small amount of tabs;
  3.b) not loaded dynamically;
  3.c) not really useful to see them side by side (if it is then the
dialog is badly designed IMHO);
  3.d) all have the same form.

Then there's a potentially infinite number of other classes for which
"tabs" can and probably should take a different form in every one of
them. For instance, Rhythmbox and Banshee have a left side bar which
allows you to change the source (or context) and those, IMO, are just
another form of tabs. Then there's things like Blender, Pitivi and a
multitude of other domain specific apps.

I think that the current GtkNotebook widget works very well for n. 3
and it could be improved to work better for n. 2. But application
authors will still have to do their own work and *design* their
applications well. For instance, if the user opens a lot of tabs I
don't think there's much that GtkNotebook alone can do. Every solution
has downsides: more than one row of tabs sucks for taking too much
screen space and generally looking cluttered; keeping a minimum tab
size and scrolling sucks because the user can't see all tabs at
glance; shrinking tabs ad infinitum sucks because then you can't read
the label and it becomes difficult to select with the mouse pointer.
The application should be designed to do something else at some point.

So, do we really want an uniform tab implementation at the WM level? I
don't think so because many apps don't want that. It doesn't make
sense to them.

If anything I think we should be pushing for *less* WM in our UI. For
instance, Karl's really nice looking mockups are not really possible
today unless we move the window decorations to the client. The toolkit
should have a reference default implementation and then provide a
flexible (how much is debatable[1]) API for applications to put things
there. Tabs could be one thing among many. There are other benefits
like consolidating the WM theme and the toolkit theme into one thus
making the life of our artists easier.

OK, this was my completely uninformed opinion, thanks for reading anyway.

Rui

[1] We really don't want to see every application go wild and do this
differently. At least what's officially shipped in Gnome is under our
control and should follow strict rules about this.