-
Notifications
You must be signed in to change notification settings - Fork 0
Home
I recently decided to jump into the world of tiling window managers, to see how it felt and how it worked. What were its benefits and what were its challenges.
I must say it has been a learning experience coming to terms with all the moving parts to something as "simple" as a well-behaved UI.
So as not to bore you with the details of my journey, the issue I encountered was opening up a new workspace in i3.
The default method requires me to check which workspaces are occupied, and then, choosing an free workspace, jump to that workspace. Or, upon choosing, move the container to the new workspace, then jump to that one. Besides being somewhat klunky, I found that I the tendency was to grow workspaces, leaving gaps behind.
To bind a key that would allow me to jump to the first available workspace, or move a container (and then jump) to that workspace.
I found i3-next-available-workspace. I had to download wmctrl, though I already had xdotool. One those dependencies were met, it worked out of the box. It found the minimum available workspace. Well done.
Even though, it worked, upon creating a new workspace, it only used the number as its label. That did not look right squeezed between workspaces that had predefined labels. Besides, if there was a label defined for that workspace, I wanted to use it.
By parsing the i3config file, I created a list of workspace names, and used that to move to the new workspace. This caused it to correctly name the workspaces.
Now that all else was working, I wondered if I need to call external programs
Wmctrl was no problem. i3-msg had get_workspaces, though it required jq to extract the information, but it did not need xprop anymore either.
It is quite self-contained and it's only dependency is now jq. And, amazingly enough, it works. It will even create another workspace (beyond what you have defined), if asked.
- Workspace names
The only slight enhancement is to automate the creation of the list. At present this list is created each time the script is invoked.
The solution would be to read and store. Then it would require either storing the date, and comparing it to the last mod time of the i3config file, or being alerted to a change on the i3config file, which would automatically trigger an update of the list. The final, more radical solution, would be to remove the definition of the workspaces from i3config and place it in a separate file. This file would then be accessed upon each run, unless it had not changed since the last run. All these solutions are possible, but, at present, the cost of reading the i3dconfig file is not prohibitive, and thus is satisfactory.
- Remove all external depencies
Using jq makes it more robust. I could grep the information out of the json structure, however, if there was a change of schema - that could impact the search, and it would require a call to an external program anyway - though perhaps a different one.
- Cycle through workspaces
It would be nice to have the same sort of key like <ALT+Arrow> to cycle through the active workspaces. Even perhaps announcing them (i3-blocks?).
- List of containers
I can dream, can't I?
Of a little blocklet that would throw up all the containers,and their windows - allowing to move or arrange them accordingly.
But just to see them all, would be excellent too!
Like a map of what is happening on the i3-tree.
Thank you to @jytrowbridge for the inspiration in leading me in the correct direction.
I had a lot of fun delving into this. There are a number of enhancements to i3 that I want to tackle... but for now, this is sufficient.
JG