Clients Don't Remember Workspace

[AmeerTaweel]

Note: This was originally posted on r/herbstluftwm on reddit. I got recommended to post it here.

I recently switched from AwesomeWM to HerbstluftWM mainly because I didn't like automatic tiling. However, I'm facing an annoying issue with HerbstluftWM.

Let's say I have a Chrome window (call it X) open on workspace 1, and another Chrome window (call it Y) open on workspace 2.

I reboot/shutdown, then open Chrome. On AwesomeWM, X opens on workspace 1, and Y opens on workspace 2. However, on HerbstluftWM both X and Y open on workspace 1.

Of course, I can just move Y to workspace 2 and live my life. The problem is, I have exactly 51 such open windows, spread across 10 workspaces. So putting everything in place after each reboot/shutdown is so annoying.

I looked on the internet and in the documentation, but didn't get anywhere...

I would appreciate any help with this.

[cbf305]

Here from the Reddit post...

You can somewhat achieve this with rules. It will take a little effort and it's not a perfect match to what you are after, but it should get you close.

You can chain a one time use rule with spawn. Let's say you want to launch a terminal on tag X. You could do so with (where "terminal" is your terminal of choice):

herbstclient chain . rule once tag=X . spawn terminal

Once the terminal launches on tag X, the rule is gone. So you could add rules like these at the end of your autostart to load stuff when you login. You can even add the focus=on and/or switchtag=on parameters to the rule to automatically switch to tag X, launch the program and then focus it. The previous example would look something like this:

herbstclient chain . rule once tag=X focus=on switchtag=on . spawn terminal

You can also set this to a keybinding if you don't want it to start at login.

You can also just have general rules loaded all the time. Let's say we have the following rule for alacritty in the autostart file:

rule class~'[Aa]lacritty' tag=X

This rule says anytime a window with class "Alacritty" or "alacritty" is spawned place it on tag X. You can do this for any program as long as you can target it with the rule. Of course you can always move the window anywhere you want once it is spawned. Some programs will allow you to specify the window title at launch, so you could set something in there to use as a target for the rule. I am not sure if Chromium allows custom window naming, but Google Chrome for sure does not. So you would not be able to have a general rule to always spawn Chrome X on one tag and Chrome Y on another, but you could use those rule once chains:

herbstclient chain . rule once tag=X . spawn google-chrome-stable
herbstclient chain . rule once tag=Y . spawn google-chrome-stable

If you use separate profiles for Chrome X and Y, you could pick which one to launch where by adding the --user-data-dir=PATH flag to both of those.

None of this will make HLWM remember what is open at the time of logout and put it all back when you log back in. I personally don't like things auto-starting at login, so I use the rule once with keybinds or craft a general rule to target specific programs as I need them.

[AmeerTaweel]

Thanks for your help. As you mentioned, this is not exactly what I want. I really like the manual tiling aspect of HerbstluftWM, but this issue is a very annoying to me. I think I will try bspwm and see if they have the same issue or not.

[wimstefan]

awesomewm does have that feature.
So I'm switching back and forth between the two 😏

[bew]

I'd be interested if you know how awesome was identifying each windows to be able to place them back in the correct tags 🤔

[AmeerTaweel]

I actually have no idea whatsoever 😂

[etosan]

That would be exactly my question - how the fuck does awesome do this? Figure that out and you are set to go.

Easy rider

For simpler software of ye olde times you could easily use temporary rule and what I call a "PID hack":

• wrap executable of the program with wrapper script
• before running program register temporary rule to hlwm for window with given PID to bind to certain tag
• exec into program in question - this way the actual target of the rule will run in PID of the wrapper script thus all the windows it spawns will match the rule

This is what I use with mpv for example:

: cat =mpv
#!/bin/sh

MPV_AUDIO_DEVICE="$(cat /run/user/eto/program-state/mpv/audio-device)"

HC_FOCUS_TAG="$(hc attr tags.focus.name)"
HC_RULE_EXPIRE=120
HC_MPV_PID="${$}"

hc rule prepend maxage="${HC_RULE_EXPIRE}" pid="${HC_MPV_PID}" tag="${HC_FOCUS_TAG}" once

exec /usr/bin/mpv --audio-device="${MPV_AUDIO_DEVICE}" "$@"

I do this, because I only watch youtube through mpv and had this annoying issue: each time I wanted to watch a vid, it takes quite a lot time, till decrapware yt-dlp script extracts data and urls needed for mpv to play the vid (sometimes this can be a minute or even more), so I often switched to other tag, to do something else, but once video got finally loaded, window jumped right into my face on focused, but compeletely unintended tag (the one I quickly switched to while waiting, not the one where I was meaning to watch it).

The script above ensures, that video always starts on tag from which it was spawned from. I know that video started by hearing sound, so then I just switch back, to the tag, where it is playing (it's trivial to rewind a "lost" second). This way I don't have to stare at a mpv console slowly downloading the vid, gentoo way :).

Browser dances

In your case this is however more problematic: you are using a browser.

With a browser (which is smelliest piece of software one can have on a desktop) mapping of PID to window is tragic ordeal and would not work - probably. Even more: modern browsers are such bag of bloated mess that, each is basically it's own OS by now, running dozens IPCing processes with hundredths of threads, eating memory like crazy and bringing even most modern and fastest desktops to shitty crawl (especially chromium :), but firefox is bullshit too). This means that with modern browsers the map between processes and their windows can even be M:N random chaos (not sure, don't care).

What to do? This how I do it, maybe it helps you too.

I am anti-google so firefox here is better choice than googlium: I actually run multiple concurrent firefoxes (like for real - not just "windows" and "containers" (or how they call their tragic kiddy level tab isolation crap) - actual whole mutiple process swarms) for seperation of concerns: work web guis (vcenters, fibre channel switches, tape libraries, disk arrays and other clickety infrastructural interfaces) live in different firefox, than general "research" pages or "office" communication (teams, office 365, etc) are another firefox swarms, personal browsing is yet another firefox, banking is even other and so on. I guess you get the picture. Most of the time, only few of these "foxes" are running.

Some of these "foxes" are also enclosed into their own network namespaces, for example to prevent "infrafox" from accidentaly and unintentionally waltizing onto the raw internet, but that is implementation detail, do whatever you need to do.

I then use a firefox extension which prefixes each window title with some string (in my case it is ff:infra, ff:office, etc., you get the gist) depending on the active firefox profile.

Finally, I have bunch of rofi organized scripts that carefully parse window titles and WM classes (be careful as web pages can inject anything into the window title), and know how to send given firefox windows to manually specified tag.

So this way I can send all the ff:infra to tag A and ff:office to tag B.

Sounds little bit crazy but is pretty flexible in the end. I am quite happy with it.

How awesome does it?

As far as I remember awesome was pretty heavily lua based. And with lua, sky is the limit.

Thinking about it, I believe awesome must then be somehow recording window:tag maps for chrome's wmclass. And storing it in some kind of persistent storage (database). Yuck, not a feature I would want my wm to do without telling me. Because X window IDs are ephemeral, I don't think is storing those - I would bet that it is somewhere storing full browser windows titles - hmm what have you watched recently? :)

You should check the code. If that is your case, than solution could be "easy", you just need to write a script that will iterate over all the tag clients and if they are chrome windows, then store them in title:tag map (in sqlite or whatever).

Call it save-chrome-window-tag-map or something. Then you need to write separate script restore-chrome-window-tag-map. Then just before shutting off, you would run the save script, and after the reboot and after the browser starts the restore script.

This would be the easiest way.

Should this work, you could also extend this to run periodically. Prune db for non existing windows on restore, etc.

Doing this automatically as chrome windows spawn could eventually be done, but I believe atm herbst still lacks a few bits to do this efficiently. But we will get there eventually.

But still, with scripts, you get clearer separation of concerns though, and you can bind them to keybinds etc. and overall do much more than awesome ever could.

Conclusion

@t-wissmann in one presentation once said that hlwm is for those who want to put in the hours customizing it. This is such a case. In my experience it is well worth it.

[AmeerTaweel]

Thanks for the useful tricks @etosan!

But after what you said, I think organizing my tabs better (closing 99% of them that I don't use) is the way to go lol.

[bew]

Now that you mention the id @etosan, I kinda remember how awesome does it: The freedesktop startup notification.
In each client in awesome (clients are the windows), you have access to the property startup_id.
Now I remember digging (a loong time ago, I was on awesome before hlwm!) even into the source code to understand the same thing, how it remembers the tag / how to match thd window to the original tag..

From the Lua doc about that property (https://awesomewm.org/doc/api/classes/client.html#client.startup_id):

When a client is spawned (like using a terminal or awful.spawn, a startup notification identifier is created. When the client is created, this identifier remain the same. This allow to match a spawn event to an actual client.

This is used to display a different mouse cursor when the application is loading and also to attach some properties to the newly created client (like a tag or floating state).

And in the doc of awful.spawn the module used to spawn things in awesome (https://awesomewm.org/doc/api/libraries/awful.spawn.html) there is more info for this startup notification in the top section Spawning applications with specific properties:

The startup notification protocol:

The startup notification protocol is an optional specification implemented by X11 applications to bridge the chain of knowledge between the moment a program is launched to the moment its window (client) is shown. It can be found on the FreeDesktop.org website (https://www.freedesktop.org/wiki/Specifications/startup-notification-spec/).

Awesome has support for the various events that are part of the protocol, but the most useful is the identifier, usually identified by its SNID acronym in the documentation. It isn’t usually necessary to even know it exists, as it is all done automatically. However, if more control is required, the identifier can be specified by an environment variable called DESKTOP_STARTUP_ID. For example, let us consider execution of the following command:

DESKTOP_STARTUP_ID="something_TIME$(date '+%s')" my_command

This should (if the program correctly implements the protocol) result in c.startup_id to at least match something. This identifier can then be used in awful.rules to configure the client.

Awesome can automatically set the DESKTOP_STARTUP_ID variable. This is used by awful.spawn to specify additional rules for the startup.

Note that the client.startup_id isn’t supported by all applications and a Linux-specific workaround is recommended to improve the reliability of the awful.spawn functions.

[Akshaybun]

Can't we achieve this with script?

1. loop over all tags and dump save their layouts
2. find out each clients associated class
   // after restarting
3. run all these classes instances
4. get all active clients winid
5. replace old winids in saved layouts with new winids
6. loop over all tags and Load these layouts

Though It won't be able to handle positions of more than one similar instances.