Monochromatic

z3bra, the stripes apart

Avoid workspaces

18 November, 2014

Virtual desktops considered harmful

Virtual desktops

If you're used to the Linux desktop, you might already know what virtual desktops (usally called "workspaces" too) are. If not, then RTFM here is a quick explanation:

Since the first graphical user interface, users were presented a "desktop". It's a space that covers the whole screen, where programs can be run (example). The destkop do not extends outside the screen area, thus giving only this space available for working.

Virtual desktops are an asnwer to this problem, as it gives the user multiple desktops to work with. He/She can only see one desktop (or workspace) at the time, but can easily switch to any of them.

-- Me

Tilling WM makes heavy use of these, as they can't display many windows at the same time without rendering the desktop unusable.

But this behavior do not give an answer to the main problem!

Nothing but a hack

Using virtual desktop because you lack space is like scooping water out of a boat instead of putting your finger in the hole. Sure it does the work, but it'll never FIX your problem (oh, and buying a home cinema to use for your desktop is not a solution either ;)).

Why is it not the solution then ? Let's consider the following scenario:

A C developper needs to create an application. To do so, he needs at least 3 tools:

But he might get stuck at some point, and require a man page, or help from forums:

Note that he also is a fervent chatter, and can't leave without an IRC window oppened somewhere. He also need to check is e-mails from time to time

This poor guys also like to monitor his system heavily, and thus uses a few monitoring applications:

This developper obviously has a really small screen, so he can(t view many windows at the same time.

You have 3 hours, and I retrieve the drafts.

What would the typical workspace approach be ?

  1. group windows by "theme", and assign each of the to a workspace:
    • development : editor + compiler + terminal + man pages
    • net stuff : web browser + mail + IRC
    • monitoring : netstat + ps + free
  2. switch to a desktop when there is a need for it
  3. change application's desktop when needing to view an app from both desktop

This might do it. But let's say he also want to check how his application affect his system, does he have to switch to the "monitoring" workspace right after launching his app ? What if it's an interactive program ? Do you think it will be efficient to switch constantly between the "monitoring" and "development" desktops ? NO, it is not.

Our dev could also move his application to the monitoring desktop, yeah nice idea. I hope it's not a a web application then... Because we would have to add the browser to this desktop too. And even if he manage to do it, he will still have to tidy his desktops again when he's done (sending back applications to their "native" dekstops.

All these operations result in a lot of efforts, because you constantly have to switch from one desktop to another, send windows to specific desktop and then sending them back. What's the point of having a powerfull operation system if it require so much efforts to run it ?

A better window management

I arrange my windows in groups. Then I send them back and forth whenever I need them -- unknown

I can't remember where I read that, or who said it. But that pretty much sums up what I'm about to say.

Instead of putting windows together by "theme", you should be able to show or hide whenever you need them. Sort of what you would do with a task bar, but with groups of windows instead of single instance.

What do I mean ? Let's take our example from above. instead of grouping windows by theme, we group them by task. We have five main tasks here:

First, only "coding" is visible. We then bring "compiling" to the foreground when we need it. Then we send back "coding", and call "testing". To monitor the system meanwhile, hide "compiling", show "monitoring". And so on...

Here's the keypoint: multitasking is not about switching between tasks. It's about doing them when they're relevant. Monitoring your system and testing a program are two different tasks. But those two might be linked at some point, and it should not be painfull to work on both of them at the same time.

Final word

Maybe I convinced you, maybe not. Either way, it should not stop you from trying it, at least once. The groups I'm speaking about are fully implemented in the cwm window manager. Once I tried it, I could not go back.

As I missed it in other WMs, I started working on an external app to reproduce this behavior. We (dcat and me), ended up writing wmutils, which allow complex groups management.

Also, as per tradition, here is a video of what it looks like.

video: mp4

this video illustrate the previous example showing how groups works, using a forked version (not maintained anymore) of 2bwm.