Author: z3bra <email@example.com>
Date: Tue, 18 Nov 2014 21:48:56 +0100
new post !
1 file changed, 150 insertions(+), 0 deletions(-)
diff --git a/2014/11/avoid-workspaces.txt b/2014/11/avoid-workspaces.txt
@@ -0,0 +1,150 @@
+# [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
+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, on which programs, can be run
+> 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.
+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
+> * editor
+> * compiler
+> * terminal
+> But he might get stuck at some point, and require a man page, or help from
+> * man pages
+> * web browser
+> 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
+> * IRC chat
+> * mail client
+> This poor guys also like to monitor his system heavily, and thus uses a few
+> monitoring applications:
+> * netstat
+> * ps aux
+> * free -mh
+> 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
+<q>I arrange my windows in groups. Then I send them back and forth whenever I
+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:
+* coding : editor
+* compiling: compiler
+* testing : terminal
+* searching : man page + browser
+* monitoring : ps aux + netstat + free
+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. I ended up creating [`gm`](http://git.z3bra.org/cgit/cgi/gm). It
+is still in early alpha state so many changes may occur in the following weeks,
+until I decide to release v0.1. Happy testing !
+Also, as per tradition, here is a video of it running.
+<video controls src="/vid/2014-11-18-groups.mp4">
+there should be a video here..
+<span class="caption">this video illustrate the previous example showing how
+groups works, using a [forked version](http://git.z3bra.org/cgit.cgi/2bwm) of
+<!-- vim: set ft=markdown ts=4 et tw=80: -->