monochromatic

monochromatic blog: http://blog.z3bra.org
git clone git://z3bra.org/monochromatic
Log | Files | Refs

avoid-workspaces.txt (5787B)


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