1. 14

The author suggests using window groups instead

  1.  

  2. 11

    As far as I can tell, this is a revival of dwm’s tags/views model.

    While, apparently, many dwm users use tags as if they are workspaces, that is only a fraction of their potential; and, when used properly, they can offer a workflow identical (from my perspective) to the one mentioned in the post.

    cf. tags are not workspaces.

    This is not to say that the author is wrong or is stealing and should give credit or anything like that. It is only to suggest that this paradigm has been known and is available in some window managers.

    Now, here’s where my knowledge of the subject gets a little thin. Where dwm supports this paradigm, I am unsure as to whether or not its many derivatives do (e.g., awesomewm, xmonad, etc.). I’d be interested in hearing from those users if this type of configuration is possible (presumably, anything is possible in xmonad since it’s really just a WM library and you can have whatever logic you’re willing to program, but I more meant, well-supported and easy to achieve through minor configuration changes).

    1. 4

      Awesome supported this, I believe. I remember having Win+[1-9] set to switch between tags, and when I would accidentally hold control when switching I would get windows from both tags!

      I like the idea of this, but I struggle with the execution when bringing in another tag causes overlaps or forces my current workspace to rearrange. For example, if I had chat and a browser open together taking up most of the screen while dealing with some operational issue, adding the editor group/tag to the screen would either overlap (if things were floating) or rearrange/resize existing windows (if some kind of tiling).

      To those that use the group/tagging feature in the way described in the post, how do you deal with the overlap or resizing issue?

      1. 1

        I fix the areas, so I don’t say «give me also group X», I say «please put group X in this subarea (and — in majority of cases — remove everything else from this subarea) without touching the rest of my screen»

        1. 1

          I have pretty much the exact shortcuts you describe. I use tiling mode almost exclusively, so I expect it when I look at two at once. It seems totally normal. I also have super + J and K for moving windows up and down in the current order.

        2. 3

          I’m not running xmonad at the moment, but it seems like xmonad-contrib has a XMonad.Actions.TagWindows module that does this.

          1. 3

            dwm’s tags are indeed capable of handling that workflow I describe in this post, and even more IIRC. My first experience with groups came with cwm which lets you add windows to a group. Doing so would automatically remove the window from any other groups. With dwm, a single window can have multiple tags, thus allowing finer control over your task set, and which application to bring back and forth. This might be a little more complex to manage though, as you are responsible from adding AND removing windows from tags. Automatic removal from groups is, to me, the best compromise between workspace and tags.

            1. 5

              Meh. I’m not sure it’s valid to extrapolate “This is the best solution for me,” into “This is the best solution for everybody,” in this case. Everybody’s going to have their own preferences and their own workflow that makes them most efficient.

              I’d guess the productivity gains around more efficient window switching must be pretty minimal, anyway.

              1. 1

                Well, there is time saved (not much), energy saved (probably not much, either) and avoided hatred to the entire idea of a computer (that can depend on personality)

                I would say that «global workspaces with each window in exactly one workspace and switches changing everything at once» is indeed too simplistic to be a non-annoying solution; specific solutions differ.

              2. 4

                I used wmii for over 10 years because of the tagging. I haven’t found a “fork” or “clone” that has all the same elements of tiling, tagging, multi-tagging, and dynamically named tags.

                I recently gave up (as wmii is long since unmaintained) and got i3 as close as I could to my workflow but without multi-tagging. Maybe there is one that does all of this that I’ve missed. Or I can sort of cobble together my own window management with some scripts and utilities.

                1. 3

                  Transitioned to i3 from wmii myself, and I miss the multi-tagging too. Otherwise i3 is a solid piece of work. I wonder how difficult it would be to hack in multi-tag support in i3. Have you looked into i3’s code base?

                  1. 2

                    What is multi-tagging? Assignment of multiple tags to a window? Isn’t this a part of definition of tagging in the first place?

                    (I ask because at some point I have implemented tagging for StumpWM, which of course supports assigning many tags to a single window; then ended up using only one tag for each window in practice — because making groups per-screen-subarea turned out to be more convenient than multi-tagging and global groups)

                    1. 2

                      I haven’t looked into that. I switched recently. If I had the programming skills, though, I would have cleaned up and maintained wmii.

                  2. 3

                    In my personal setup, multiple “virtual desktops” (workspaces, how he calls them) work like a charm. I’m so used to them, with all the keyboard “shortcuts” that working with a single one is little frustrating.

                    I wouldn’t consider it “harmful”, different people work differently.

                    1. 1

                      I think the author isn’t even considering just a single workspace with all windows always there as a viable option. Multiple workspaces are criticized not for being different from single workspace, but for not being different enough.

                    2. 2

                      In my case the solution ended up being «the problem with workspaces is that they are global».

                      I have a multi-tagging system implemented for StumpWM, but in reality almost all the tags are assigned automatically by very simple criteria (there is approximately one exception that should not be fixed by writing one more script). And the tags I actually use are almost always one-per-window.

                      What I do use heavily, though, is that I have a few commands to resplit the screen, and then I assign a set of windows by tag to an area, not globally. Global workspaces with no overlap are, indeed, not powerful enough.