tavoid-workspaces.txt - monochromatic - monochromatic blog: http://blog.z3bra.org
 (HTM) git clone git://z3bra.org/monochromatic
 (DIR) Log
 (DIR) Files
 (DIR) Refs
       ---
       tavoid-workspaces.txt (5678B)
       ---
            1 # Avoid workspaces
            2 
            3 18 November, 2014
            4 
            5 > Virtual desktops considered harmful
            6 
            7 ## Virtual desktops
            8 
            9 If you're used to the Linux desktop, you might already know what virtual
           10 desktops (usally called "workspaces" too) are. If not, then
           11 <del>[RTFM](https://en.wikipedia.org/wiki/Virtual_desktop)</del> here
           12 is a quick explanation:
           13 
           14 > Since the first graphical user interface, users were presented a "desktop".
           15 > It's a space that covers the whole screen, where programs can be run
           16 > ([example](http://upload.wikimedia.org/wikipedia/commons/d/d4/X-Window-System.png)).
           17 > The destkop do not extends outside the screen area, thus giving only this
           18 > space available for working.
           19 > 
           20 > Virtual desktops are an asnwer to this problem, as it gives the user multiple
           21 > desktops to work with. He/She can only see one desktop (or workspace) at the
           22 > time, but can easily switch to any of them.
           23 
           24 <cite>-- Me</cite>
           25 
           26 Tilling WM makes heavy use of these, as they can't display many windows at the
           27 same time without rendering the desktop unusable.
           28 
           29 But this behavior do not give an answer to the main problem!
           30 
           31 ## Nothing but a hack
           32 
           33 Using virtual desktop because you lack space is like scooping water out of a
           34 boat instead of putting your finger in the hole. Sure it does the work, but it'll
           35 never FIX your problem (oh, and buying a home cinema to use for your desktop is
           36 not a solution either ;)).
           37 
           38 Why is it not the solution then ? Let's consider the following scenario:
           39 
           40 > A C developper needs to create an application. To do so, he needs at least 3
           41 > tools:
           42 >
           43 > * editor
           44 > * compiler
           45 > * terminal
           46 >
           47 > But he might get stuck at some point, and require a man page, or help from
           48 > forums:
           49 >
           50 > * man pages
           51 > * web browser
           52 >
           53 > Note that he also is a fervent chatter, and can't leave without an IRC window
           54 > oppened somewhere. He also need to check is e-mails from time to time
           55 >
           56 > * IRC chat
           57 > * mail client
           58 >
           59 > This poor guys also like to monitor his system heavily, and thus uses a few
           60 > monitoring applications:
           61 >
           62 > * netstat
           63 > * ps aux
           64 > * free -mh
           65 >
           66 > This developper obviously has a really small screen, so he can(t view many
           67 > windows at the same time.
           68 
           69 You have 3 hours, and I retrieve the drafts.
           70 
           71 What would the typical workspace approach be ?
           72 
           73 1. group windows by "theme", and assign each of the to a workspace:
           74     * development  : editor + compiler + terminal + man pages
           75     * net stuff    : web browser + mail + IRC
           76     * monitoring   : netstat + ps + free
           77 2. switch to a desktop when there is a need for it
           78 3. change application's desktop when needing to view an app from both desktop
           79 
           80 This **might** do it. But let's say he also want to check how his application
           81 affect his system, does he have to switch to the "monitoring" workspace right
           82 after launching his app ? What if it's an interactive program ? Do you think it
           83 will be efficient to switch constantly between the "monitoring" and
           84 "development" desktops ? NO, it is not.
           85 
           86 Our dev could also move his application to the monitoring desktop, yeah nice
           87 idea. I hope it's not a a web application then... Because we would have to add
           88 the browser to this desktop too. And even if he manage to do it, he will still
           89 have to tidy his desktops again when he's done (sending back applications to
           90 their "native" dekstops.
           91 
           92 All these operations result in a lot of efforts, because you constantly have to
           93 switch from one desktop to another, send windows to specific desktop and then
           94 sending them back. What's the point of having a powerfull operation system if it
           95 require so much efforts to run it ?
           96 
           97 ## A better window management
           98 
           99 <q>I arrange my windows in groups. Then I send them back and forth whenever I
          100 need them</q>
          101 <cite>-- unknown</cite>
          102 
          103 I can't remember where I read that, or who said it. But that pretty much sums up
          104 what I'm about to say.
          105 
          106 Instead of putting windows together by "theme", you should be able to show or
          107 hide whenever you need them. Sort of what you would do with a task bar, but with
          108 groups of windows instead of single instance.
          109 
          110 What do I mean ? Let's take our example from above. instead of grouping windows
          111 by theme, we group them by task. We have five main tasks here:
          112 
          113 * coding : editor
          114 * compiling: compiler
          115 * testing : terminal
          116 * searching : man page + browser
          117 * monitoring : ps aux + netstat + free
          118 
          119 First, only "coding" is visible. We then bring "compiling" to the foreground
          120 when we need it. Then we send back "coding", and call "testing". To monitor the
          121 system meanwhile, hide "compiling", show "monitoring". And so on...
          122 
          123 Here's the keypoint: **multitasking is not about switching between tasks. It's
          124 about doing them when they're relevant**. Monitoring your system and testing a
          125 program are two different tasks. But those two might be linked at some point,
          126 and it should not be painfull to work on both of them at the same time.
          127 
          128 ## Final word
          129 
          130 Maybe I convinced you, maybe not. Either way, it should not stop you from trying
          131 it, at least once. The groups I'm speaking about are fully implemented in the
          132 `cwm` window manager. Once I tried it, I could not go back.
          133 
          134 As I missed it in other WMs, I started working on an external app to reproduce
          135 this behavior. We (dcat and me), ended up writing
          136 [wmutils](http://github.com/wmutils/core), which allow complex groups
          137 management.
          138 
          139 Also, as per tradition, here is a video of what it looks like.
          140 
          141 <video controls>
          142     <source src="http://pub.z3bra.org/monochromatic/vid/2014-11-18-groups.mp4" type="video/mp4">
          143 </video>
          144 
          145 video: [mp4](http://pub.z3bra.org/monochromatic/vid/2014-11-18-groups.mp4)
          146 
          147 *this video illustrate the previous example showing how
          148 groups works, using a [forked version](git://z3bra.org/2bwm) (not maintained
          149 anymore) of `2bwm`.*