2009/7/13 Karl Lattimer <k...@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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list