-
The gnome-shell gang has been furiously working on a new scheme for presenting multiple workspaces. Today I played a bit with Oralia's Mac to see how it handles workspaces. Here are some observations.
The mental model
This is a screenshot of the preferences window for workspaces. We'll discuss each section individually.
First, let's start with the mental model. This is similar to what we had in Gnome 2 — workspaces are arranged in a rectangular grid. To avoid remainders, MacOS lets you add whole rows and columns of workspaces to that grid, instead of letting you choose an arbitrary number of workspaces. Each workspace gets a number, and the numbers always go left-to-right and then top-to-bottom. You can have a maximum of 16 workspaces, which of course get numbered as
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
If you enable "Show spaces in menu bar", then you get an icon in the menu that shows you the number of the current workspace. If you click that icon, you get this plain menu (assume 4 workspaces):
1
2
3
4
---------------------------
Spaces preferences...(This of course looks like ass; it would be better as the same grid that you have in your mind.)
Switching options
You can configure Ctrl+arrows (or arrows plus another modifier) to switch among workspaces based on the grid. Ctrl+down will move you to the workspace below the one you are in, and so on for the other arrow keys.
You can configure Ctrl+numbers (or another modifier) to switch directly to workspaces based on their number. If you press Ctrl+1 you'll switch to the first workspace; Ctrl+2 for the second workspace; etc. This is what I like the most, as it closely resembles the scheme that I have in Gnome 2 at present: in my machine, Alt+F1 through Alt+F10 switch me to workspaces 1 through 10. This gives me instantaneous touch-type access to my workspaces.
Navigator
The navigator is overlaid on your desktop's contents whenever you switch workspaces. The white rectangle in the navigator is your current workspace, and it slides to the new workspace you are switching to. This lets you always see where you are in the grid.
When you press Ctrl+number to switch to a specific workspace, the navigator appears briefly, then the white rectangle slides to the destination workspace, and the navigator then disappears. Metacity lacks this.
When you switch with Ctrl+arrows, the navigator stays visible for as long as you hold down Ctrl, just like Metacity.
My thoughts on workspaces
People use workspaces in various ways, and it would be very instructive to watch a few people work (or to ask them) to see just how they use them.
I'm the kind of person that likes to dedicate each separate workspace to a distinct activity. My "always on" windows always go in the same workspace numbers: Emacs windows in workspaces 2/3/4, Banshee in workspace 5, Evolution in 6, Firefox in 7. I maximize each of those windows.
Since those windows are always in the same place, I can switch very easily to them using Alt+F1 through Alt+F10 as discussed above (MacOS would default to Ctrl+1 through Ctrl+0, but it's the same idea). Since my "always on" windows are maximized most of the time, I effectively get single-keystroke access to all of them.
Of course I sometimes dedicate other workspaces to tasks where I need multiple windows or multiple applications. I may have a workspace with Firefox and Evince for researching stuff (e.g. you browse the web and click on a PDF, which opens Evince), plus a little Emacs window for taking notes. I may have a workspace dedicated to the GIMP, because it's just impossible to keep its many windows in order if you let them overlap with other apps.
However, I understand that I have smallish monitors — my laptop's 14" screen plus an external 19" monitor. People with huge, high-resolution monitors may have less of a need for workspaces, since they can actually fit several big windows on the screen at the same time.
Brief critique of gnome-shell
I haven't had a chance to test the latest state of the overview-relayout branch in gnome-shell since the Summit happened. So this is a totally uninformed opinion, since I haven't actually run Jimmac's latest plan.
The thing that bothers me about gnome-shell's workspaces is that they are totally on-demand: you always start with one workspace, and you create more as you need them. I understand the thinking behind this — "as much space as you need, all the time!" — but I feel more comfortable with getting a big desk once, and then figuring out the best place to put my commonly-used tools. I don't like starting with a coffee table and then adding more tables until I achieve a large enough surface, every time that I log in.
About a linear vs. a grid presentation... I'm not sure. A grid makes the overall layout more compact, and easily navigable with the arrow keys. You can make ad-hoc arrangements of related windows in adjacent workspaces — I often use "Emacs above, terminal below" and switch between them with Alt+Up and Alt+Down when writing code. Gnome-shell wouldn't let you do that easily without the grid view. However, if it gave you almost instantaneous access to adjacent workspaces in the list, things may work equally well.
Out there in the real world
There are some interesting patterns in the way people organize their tools in the real world.
Think of an old-style photography darkroom. The room is split in two sections, the wet area and the dry area. The wet area is where you deal with chemicals and water: you prepare the developer/stop bath/fixer, shake your photographic film inside containers with those chemicals, and you are not afraid of spilling things. You have a sink with a water faucet in that area. On the other section of the room you have the dry area. There you have your photo enlarger (a big contraption with a light source and a lens, to project the film's images into photo paper), and things like cutters and cutting mats. As you work in the darkroom, you stay in the wet or dry area for a while, and you may eventually switch to the other one.
Now think of a woodworking shop. The center of the action is the woodworker's bench, which is a big, heavy table with some vises for clamping the wood and working on it. On another section of the shop you may have an assembly or finishing table, which is lower than the workbench so you can assemble a whole cabinet on it. You glue things on that table and apply wet finishes there, as you don't want all that gunk to spill on your precious workbench. On another section of the shop, you may have a table for sharpening your tools with a grinder, whetstones, etc. Over a session of woodworking, you may switch between the different sections of the shop — cut some wood and shape it, then test the assembly, then sharpen the tools that got dull, as you need them.
In a kitchen, you want the fridge close to the sink and to the preparation area, so you can wash things and chop them. You want the stove close to the preparation area, and you want the spices close to the stove. As you cook, you move among the different areas. You don't want a huge kitchen, as you would waste much effort in moving from one area to another — rather, you want a kitchen with just enough space in each area and with the areas in a compact layout.
My point is that work has well-defined sequences with physical areas for working. You switch between those areas as the work requires it, but you always have those areas set up — you don't make them up as you go.
(And the layout is of course fractal. The woodworking shop has different areas, but the area around the workbench has all your tools, and you use them in a specific order — saws and planes to get the wood ready for joinery; saws and chisels for the actual joinery; various gadget-y tools for final shaping. Each sub-group of tools gets its space in the tool rack, with the most frequently used tools being closest to the workbench itself.)
Perhaps one problem with computers is that our "tools" are too general-purpose: applications do too much stuff. So, they don't really let you arrange the tools in a good fashion; you are always in one big app or another one, and you can't really rearrange things inside them.
-
I missed the Boston Summit last year, so I was delighted to be in this year's. I love seeing you people again!
Gnome-Shell and the journal
I had basically a single purpose during this Summit, to convince the gnome-shell people that the shell should use Zeitgeist as the foundation for the journal that shows the user's work.
Jon McCann posted this a few months ago:
What is “finding and reminding”? Generally, having a simple and effective way to keep track of, recover, and be reminded about various types of content and information.
Finding and reminding is the terminology from a key paper in human/computer interaction (and also see its followup paper from a few years later).
Jon's blog post is expanded in the Finding and Remiding whiteboard for gnome-shell, which presents the mockups for a journal-like thing in gnome-shell.
The tl;dr version of those papers and those mockups is essentially that you need a time-based view of the work you create or of the stuff you browse, instead of making you place everything into neat hierarchical boxes all the time. However, right now gnome-shell's display of Recent Documents is not much better than what we have in GNOME 2.
(Digression: while looking for children's books, I ran into Little Miss Tidy. She keeps her house in perfect order all the time. She has a pretty box for everything. But she has so many boxes in perfect order that she doesn't remember where she put things. This book evidently proves that hierarchical file management is just not convenient.)
Anyway, where was I?
There was a session during the Summit to discuss Jumplists in the shell. I came in a bit late, but let me try my hand at a not-too-inaccurate summary.
Jumplists are a feature of the Windows 7 taskbar. You click on an icon there and you get a menu that is pretty much like Tomboy's menu — a few commands, but more importantly, your most useful notes/documents/etc.
Gnome-shell wants to present useful stuff in its Applications list. For each app that is shown in there, gnome-shell wants to be able to show you the documents, or photos or whatever, that you handled with that app ("I know I used $app to do my work. Show it to me."). However, gnome-shell also wants to present you with a global list of the documents that you've handled everywhere ("I want to see what I was doing around the same time as $work").
And so the thinking went like this. We need a way to keep track of the things the user does, like creating documents or viewing photos. And we need a way to associate those things to the applications that were used to do them. And a time-based global view of your stuff would be useful. So we need to query by time and to query by app. Oh, wait, that's exactly what the Zeitgeist engine already does.
To get some gnome-shell+Zeitgeist integration going, the first thing we'll do is to make the shell's "Search" box query Zeitgeist for results, instead of poking at your recently-used list by hand. That should at least give us the necessary framework to talk to Zeitgeist from gnome-shell (Javascript bindings for Zeitgeist's D-Bus API, probably).
The real work will be to implement a journal that uses the Zeitgeist engine underneath. Gnome Activity Journal has already taught us about some things that work well in a journal, and others that don't.
Also from the summit
Dave Mason, who was the coordinator of the Gnome Documentation Project for a while, and a very dear friend from my days at Red Hat Labs, was visiting Cambridge with his wife Cate. We had breakfast together with JRB and his kids. Good to catch up.
J5 and I talked about food. He is the real deal, a studied cook, and he's building a professional kitchen for his home. We discussed the permutations of ingredients in tomato sauces.
Gustavo from Brazil told me about a Samsung fridge (I think) that uses the Enlightenment graphics framework for its display. I don't have a fridge with a display, but that sounds diabolically tempting.
After 10 or 11 years of not seeing him, I ran into the amazing David Miller as I went to dinner with Michael and Rob. It's a shame that we didn't get to talk; he blogged a while ago about "Beaux-Arts and kernel hacking" in his unlinkable blog, and that seemed like a worthwhile topic of conversation for architecture nerds.
Highlight of the trip
I get off the stairs to the subway in Porter Square station, and there's a squalid, suited, hatted, interesting old busker playing a tattered hurdy-gurdy. I ask him, "that's a hurdy-gurdy, right?". He replies and asks, "Yes. Where are you from?". "Mexico". And his whole face lights up, he grins from ear to ear, and exclaims, "Aaaah, LA ZANFONA!!!". "Indeed", I say — and as soon as I was going to start a conversation, the train arrived, and he quickly motioned me in, "you don't want to miss your train".
I should have stayed.
-
Linux Plumbers Conference 2010
I was in Boston/Cambridge two weeks ago for the Linux Plumbers Conference, and also for Gnome's Boston Summit. It was surprisingly not horribly cold in Boston; just mildly cold. Fortunately both conferences felt very productive for me.
The best thing to happen during the Plumbers conference was to sit down with Kristian Høgsberg and have him kindly brain-dump all the new graphics stack to me. For the past couple of years I had been feeling obsolete, being an old-school X kind of guy. Now everything seems to make sense again. Wayland is a simple graphics server which wisely reuses the scary bits of X (the ones you don't want to have to rewrite, such as keyboard mapping). The kernel takes care of mode-setting. Clients do direct rendering. They can also do compositing, and Kristian's demo uses a simple compositor; the idea is that something like gnome-shell would do compositing in the real world. Finally, an X server can also run as a Wayland client, and it works beautifully. Wayland can tell you when a frame is done repainting so you can sync your drawing to your monitor's scan rate. It's really beautiful and smooth.
Keith Packard and Bdale Garbee were talking about the rockets they build and their avionics hardware/software. Very cool stuff. It's just neat to see complete avionics in a 4x3cm square with various chips.
Michael Meeks was out in full force. I was happy to meet his brother, who lives in Cambridge, and who kindly invited us to a Jimi Hendrix tribute concert — heavy stuff, I tell you.
I had a long discussion with Loïc Minier about Unity. Brief summary: Canonical and Ubuntu have exploited Jane Jacobs's import replacement to great effect. It is great that they are doing Unity and other projects. It would be great if they did them outside the context of Ubuntu/Canonical, but they don't have an obligation to do so. I'm happy that Gnome lets people reuse good infrastructure in various ways; that's a healthy sign for Gnome, even if it gives us periodic angst about forking. I don't think copyright assignment will work out well for Canonical (hey, it didn't work for Ximian), but time will tell.
Tomorrow, hot gossip from Gnome's Boston Summit.