Too Busy For Words - the PaulWay Blog

I'm fired up to see what's involved in writing plugins for Compiz and Xgl. It seems to be a pretty good interface - something that's easy to add new effects into. I reckon there's a lot of visual coolness still to be written, and having this kind of environment, as well as the Open Source model to make it easy to learn from the ways of others, will mean that Compiz and Xgl have much more cool effects available than their proprietary Operating System 'competitors'.

One area to explore is the view of the workspaces. Sure, the default out-of-the-box configuration has four workspaces side-by-side, and this neatly maps onto the four side faces of a cube. But what about if you have more than four in a row? What if you have two by two? At one place I worked I had three across and two down, and I've seen some people that have four-by-four. So how does that map?

The shape we need to follow is a toroid. The first idea is to have the workspaces as panes tangential to the toroid. Two windows across get duplicated into four, you see the front of the current workspace and, behind it, a 'back-to-front' view of the same workspace. Three windows becomes a triangle formation, and more horizontal workspaces cause more faces to appear. Two workspaces vertically get seen as a 'two-sided' pane, like a picture with two sides, that gets flipped vertically when you move 'down' or 'up' a workspace. Three vertically is a triangular prism, and so on. There's no 'top' or 'bottom' faces like in a cube, so you can see across to the other workspace on the far side from where you are.

The second idea is to map the workspaces directly onto the toroid, by making them toroidal surface segments. This actually makes the display rules easier, as we don't have to have special rules for handling two workspaces vertically or horizontally. So a two-by-two workspace would have the workspace you just viewed as the nearest outer half of the toroid, the next horizontal space being the furthest outer half, the one 'below' where you were as being the nearest inner half, and the remaining workspace being the further inner half. The transformation animation between flat workspace and toroid surface segment is fairly easy to imagine.

At first glance I thought it would be a bicubic antialiased son of a bastard to do this, but then I realised that what's probably going to happen is that you break the screen up into subsegments and map them into positions on the surface of the toroid. Their location in space is actually fairly easy to calculate, even when they're flying into position to or from the torus. The user could specify the subdivision factor - less than two shouldn't be allowed, to keep the object looking nominally like a torus - and more subdivisions would make the object look more like a toroid at the expense of rendering speed and/or computation power.

And this is only the start of the possibilities. Hooray, Open Source and plug-in architectures!