[i3fyra] Manual/Automatic initialization of I3FYRA_WS is broken

[sdgoodrick]

I had i3fyra working, but after rebooting my PC (no update!), I am getting some error that is not particularly descriptive. I am on i3 version 4.22; i3fyra version 1.35

i3fyra --verbose -s A
f virtual_position(A)
f container_show(A)
f container_create(A)
m [con_id=94277602805984] floating disable, move --no-auto-back-and-forth to workspace
m [con_id=94277602805984] split h, layout tabbed, focus, focus parent
m mark i34A
f family_show(AC A)
m [con_mark=i34A] move to mark i34XAC
m [con_mark=i34A] swap mark i34C
m [con_id=94277602805984] focus
f CLEANUP()
ERROR: Your command:  [con_id=94277602805984] floating disable, move --no-auto-back-and-forth to workspace ;[con_id=94277602805984] split h, layout tabbed, focus, focus parent;mark i34A;[con_mark=i34A] move to mark i34XAC;[con_mark=i34A] swap mark i34C;[con_id=94277602805984] focus
ERROR:                                                                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ERROR: Expected one of these tokens: 'to ', 'next_on_output', 'prev_on_output', 'next', 'prev', 'current', 'back_and_forth', 'number', <string>
[{"success":true},{"success":false,"parse_error":true,"error":"Expected one of these tokens: 'to ', 'next_on_output', 'prev_on_output', 'next', 'prev', 'current', 'back_and_forth', 'number', <string>","input":" [con_id=94277602805984] floating disable, move --no-auto-back-and-forth to workspace ;[con_id=94277602805984] split h, layout tabbed, focus, focus parent;mark i34A;[con_mark=i34A] move to mark i34XAC;[con_mark=i34A] swap mark i34C;[con_id=94277602805984] focus","errorposition":"
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"}]

I will look through the script myself and try to debug this, but any insight would be appreciated

[budRich]

@sdgoodrick thanks for reporting this. Please let me know if you find something, i will look in to it myself, if i can replicate the issue. To me it look like the error, (Expected one of these tokens: 'to' ...) is related to the move command.

[budRich]

aha! m [con_id=94277602805984] floating disable, move --no-auto-back-and-forth to workspace there is no workspace target.

[budRich]

The workspace should be the name of i3fyra workspace, which if not already declared is the currently active workspace.

Can you paste the output you get from the command i3list (especially interested in i3list[WAN] and i3list[WFN])
And the command i3var get i3fyra_ws

One thing that could be a dirt-hack quick fix for you, is to set the environment variable I3FYRA_WS.
Example: I3FYRA_WS=1 i3fyra --verbose -s A

[sdgoodrick]

I'm sorry, it seems I turned off github email notifications while working at my previous job, lol. Thank you for your response!

I just reinstalled i3ass with a clean checkout.

output of i3list. It looks like I don't have i3list[WFN] set.

i3list[AWC]=94277602805984             # Active Window con_id
i3list[AWF]=0                          # Active Window floating
i3list[AWI]=31457285                   # Active Window id
i3list[AWW]=1920                       # Active Window width
i3list[AWH]=1068                       # Active Window height
i3list[AWX]=0                          # Active Window x position
i3list[AWY]=12                         # Active Window y position
i3list[AWB]=22                         # Active Window titlebar height
i3list[ATX]=0                          # Active Window tab x postion
i3list[ATW]=1920                       # Active Window tab width
i3list[ABW]=1                          # Active Window border width
i3list[APA]=94277601191360             # Active Window parent ID

i3list[WAI]=94277601191360             # Active Workspace con_id
i3list[WAX]=0                          # Active Workspace x position
i3list[WAY]=34                         # Active Workspace y position
i3list[WAW]=1920                       # Active Workspace width
i3list[WAH]=1046                       # Active Workspace height
i3list[WAN]="zen"                      # Active Workspace name
i3list[WSA]=-1                         # Active Workspace number

i3list[TWC]=94277602805984             # Target Window con_id
i3list[TWF]=0                          # Target Window Floating
i3list[TWI]=31457285                   # Target Window id
i3list[TWW]=1920                       # Target Window width
i3list[TWH]=1068                       # Target Window height
i3list[TWX]=0                          # Target Window x position
i3list[TWY]=12                         # Target Window y position
i3list[TWB]=22                         # Target Window titlebar height
i3list[TTX]=0                          # Target Window tab x postion
i3list[TTW]=1920                       # Target Window tab width
i3list[TBW]=1                          # Target Window border width
i3list[TPA]=94277601191360             # Target Window parent ID

i3list[WTI]=94277601191360             # Target Workspace con_id
i3list[WTX]=0                          # Target Workspace X poistion
i3list[WTY]=34                         # Target Workspace Y position
i3list[WTW]=1920                       # Target Workspace Width
i3list[WTH]=1046                       # Target Workspace Height
i3list[WTN]="zen"                      # Target Workspace name
i3list[WST]=-1                         # Target Workspace Number


i3list[RID]=94277601074880             # root container id
i3list[SUS]=                           # containers matching all criteria

output of i3var get i3fyra_ws:

\

I get a similar error as in the OP when I run I3FYRA_WS=1 i3fyra --verbose -s A, both on workspace 1 or the zen workspace

f virtual_position(A)
f container_show(A)
f container_create(A)
m [con_id=94277601194976] floating disable, move --no-auto-back-and-forth to workspace
m [con_id=94277601194976] split h, layout tabbed, focus, focus parent
m mark i34A
f family_show(AC A)
m [con_mark=i34A] move to mark i34XAC
m [con_mark=i34A] swap mark i34C
m [con_id=94277601194976] focus
f CLEANUP()
ERROR: Your command:  [con_id=94277601194976] floating disable, move --no-auto-back-and-forth to workspace ;[con_id=94277601194976] split h, layout tabbed, focus, focus parent;mark i34A;[con_mark=i34A] move to mark i34XAC;[con_mark=i34A] swap mark i34C;[con_id=94277601194976] focus
ERROR:                                                                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ERROR: Expected one of these tokens: 'to ', 'next_on_output', 'prev_on_output', 'next', 'prev', 'current', 'back_and_forth', 'number', <string>
[{"success":true},{"success":false,"parse_error":true,"error":"Expected one of these tokens: 'to ', 'next_on_output', 'prev_on_output', 'next', 'prev', 'current', 'back_and_forth', 'number', <string>","input":" [con_id=94277601194976] floating disable, move --no-auto-back-and-forth to workspace ;[con_id=94277601194976] split h, layout tabbed, focus, focus parent;mark i34A;[con_mark=i34A] move to mark i34XAC;[con_mark=i34A] swap mark i34C;[con_id=94277601194976] focus","errorposition":"
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"}]

[sdgoodrick]

Here's something, interesting: after rebooting and running i3fyra -a, I do get those variables set:

i3list[AWC]=94091642360016             # Active Window con_id
i3list[AWF]=0                          # Active Window floating
i3list[AWI]=16777222                   # Active Window id
i3list[AWW]=1920                       # Active Window width
i3list[AWH]=1080                       # Active Window height
i3list[AWX]=0                          # Active Window x position
i3list[AWY]=0                          # Active Window y position
i3list[AWB]=22                         # Active Window titlebar height
i3list[ATX]=0                          # Active Window tab x postion
i3list[ATW]=1920                       # Active Window tab width
i3list[ABW]=1                          # Active Window border width
i3list[APA]=94091642363568             # Active Window parent ID

i3list[AWP]=A                          # Active Window parent
i3list[AFT]=B                          # Active Window twin
i3list[AFC]=D                          # Active Window cousin
i3list[AFS]=C                          # Active Window sibling
i3list[AFF]=AC                         # Active Window family
i3list[AFO]=BD                         # Active Window relatives

i3list[WAI]=94091642358160             # Active Workspace con_id
i3list[WAX]=0                          # Active Workspace x position
i3list[WAY]=0                          # Active Workspace y position
i3list[WAW]=1920                       # Active Workspace width
i3list[WAH]=1080                       # Active Workspace height
i3list[WAN]="zen"                      # Active Workspace name
i3list[WSA]=-1                         # Active Workspace number

i3list[TWC]=94091642360016             # Target Window con_id
i3list[TWF]=0                          # Target Window Floating
i3list[TWI]=16777222                   # Target Window id
i3list[TWW]=1920                       # Target Window width
i3list[TWH]=1080                       # Target Window height
i3list[TWX]=0                          # Target Window x position
i3list[TWY]=0                          # Target Window y position
i3list[TWB]=22                         # Target Window titlebar height
i3list[TTX]=0                          # Target Window tab x postion
i3list[TTW]=1920                       # Target Window tab width
i3list[TBW]=1                          # Target Window border width
i3list[TPA]=94091642363568             # Target Window parent ID

i3list[TWP]=A                          # Target Window Parent container
i3list[TFT]=B                          # Target Window twin
i3list[TFC]=D                          # Target Window cousin
i3list[TFS]=C                          # Target Window sibling
i3list[TFF]=AC                         # Target Window family
i3list[TFO]=BD                         # Target Window relatives

i3list[WTI]=94091642358160             # Target Workspace con_id
i3list[WTX]=0                          # Target Workspace X poistion
i3list[WTY]=0                          # Target Workspace Y position
i3list[WTW]=1920                       # Target Workspace Width
i3list[WTH]=1080                       # Target Workspace Height
i3list[WTN]="zen"                      # Target Workspace name
i3list[WST]=-1                         # Target Workspace Number

i3list[WFI]=94091642358160             # i3fyra Workspace con_id
i3list[WFX]=0                          # i3fyra Workspace X position
i3list[WFY]=0                          # i3fyra Workspace Y position
i3list[WFW]=1920                       # i3fyra Workspace Width
i3list[WFH]=1080                       # i3fyra Workspace Height
i3list[WFN]="zen"                      # i3fyra Workspace name
i3list[WSF]=-1                         # i3fyra Workspace Number

i3list[CAL]="tabbed"                   # Container A Layout
i3list[CAW]=-1                         # Container A Workspace number
i3list[CAN]="zen"                      # Container A Workspace name
i3list[CAF]=94091642360016             # Container A Focused container id
i3list[LVI]=A                          # Visible i3fyra containers
i3list[LHI]=                           # Hidden i3fyra containers
i3list[LEX]=A                          # Existing containers (LVI+LHI)
i3list[SAB]=0                          # Current split: AB
i3list[SAC]=0                          # Current split: AC

i3list[XAC]=-1                         # family AC workspace number
i3list[LAL]=ACBD                       # All containers in family order
i3list[NAB]="zen"                      # family AB workspace name
i3list[NAC]="zen"                      # family AC workspace name
i3list[ORI]=horizontal                 # i3fyra orientation
i3list[MAB]=0                          # Stored split: AB
i3list[XAB]=-1                         # family AB workspace number

i3list[RID]=94091642342288             # root container id
i3list[SUS]=                           # containers matching all criteria

and now i3fyra almost works? I get a new error from i3fyra --verbose -s A:

 virtual_position(A)
f container_show(A)
f container_create(A)
m [con_id=94091642360016] floating disable, move --no-auto-back-and-forth to workspace zen
m [con_mark=i34XAB] split h
m [con_id=94091642360016] move to mark i34XAB
m [con_id=94091642360016] split h, layout tabbed, focus, focus parent
m mark i34A
f family_show(AC A)
m [con_mark=i34A] move to mark i34XAC
m [con_mark=i34A] swap mark i34C
m [con_id=94091642360016] focus
f CLEANUP()
ERROR: Could not find container for mark = i34C
[{"success":true},{"success":true},{"success":true},{"success":true},{"success":true},{"success":true},{"success":true},{"success":true},{"success":true},{"success":true},{"success":false,"error":"Could not find container for mark = i34C"},{"success":true}]

i3fyra_ws is still \, but I3FYRA_WS=-1 i3fyra --verbose -s A does seem to work now!!!

[budRich]

Great info. One thing i think might be related is that in your second i3list as you noticed, "zen" is your fyra workspace, and I assume this is not what you expect. I believe this is due to a strange thing with i3, the first keybinding to a a workspace will define the starting workspace. So try adding a keybinding like this: bindsym Mod4+1 workspace 1 before you have a keybinding taking you to zen.

[1ntronaut]

I have been having similar errors before; they were i3fyra errors, however, called through i3king rules. It did denote the same i3-msg error message though.
tl;dr: see end of post 'bottom line', apologies for the lengthy text.

I have some observations about i3zen/zenmode though:

• my env variables are set up like this: "i3FYRA_WS=4" and "I3FYRA_WS=4" (lower and uppercase i); this has never worked for me in setting the default i3fyra workspace => in stead; I just have the command move to workspace 4 run through my i3config, BEFORE setting the 'layout' variable for i3fyra's layout.

• however, autorunning i3fyra -a $layout from i3config does NOT create containers and thus also does not apply the i3fyra layout ;
  using bindkey for the same command, however, DOES create necessary containers when making floating windows tiled.

• sadly, it does create a (one) container.. only the A container if I tile a floating window this way. (disregarding the I3FYRA_MAIN_CONTAINER=C set as env variable.)

  • on the plus side ; from here on: i3viswiz window moving will create all containers AND respect the $layout for i3fyra. It does also re-apply the exact correct layout when running `i3fyra --layout $layout' explicitly through i3 keybind.
  • however, running `i3fyra --layout redo' does seem to return to a certain layout, but not the one I set (set in i3config). I assume it is a fallback to builtin 'default' values for layout.
  • strangely; it DOES correctly list last applied layout i3list[RED] as well as stored splits i3list[MAB,MAC,MBD].

• additional thoughts:

  • like @budRich ; via regular i3config, I do launch i3term instances (running a slightly modified i3info script, as well as starting i3king --verbose) as to monitor i3fyra/i3king activity. On startup, these windows launch as if they would in regular/default i3 ; they 1) do not create i3fyra containers (unless I untile + retile them manually); 2) do not adhere to $layout on launch; and 3) won't be ruled by i3king and thus will not move to their specified containers.
    I always have to manually i3fyra --float these windows twice (creating the 'A' container) and manually i3viswiz l|d|u|r them into their supposed containers (B+D). I also have to spawn 2 additional windows and move them around to be able to attain my preferred layout ; with 4 visible containers (i3list[LVI]), in the correct layout. I do this every time I login/start up i3, after which it will work. (P.S. i3viswiz moving does the trick. i3fyra -m A|B|C|D does NOT.. and also won't move windows to containers if I don't i3viswiz move them manually to create ABCD containers beforehand.
  • another thing I have tried is re-running/re-init i3king (kill -USR1 $(< "$XDG_RUNTIME_DIR/i3ass/i3king.pid") , but this doesn't seem to affect the 2 i3term instances mentioned above. The same command DOES however, correctly reload/update i3king rules from i3king config file.

---

tl;dr bottom line

• It seems the order in which i3fyra/i3king/i3term are launched could be of significance here, though in experimenting with this, I cannot achieve the correct/intended initialization of the i3ass components.

• Would using i3term --autotile maybe interfere with assigning i3fyra containers through i3king rules? and thus causing i3fyra to not recognize them / prevent init and applying $layout on i3 launch?

• Regarding i3zen; I run 'move to workspace 4' in i3config as a workaround for i3fyra not respecting i3FYRA_WS. If I do not, i3 will default to the first workspace in alphabetical order ; if your workspaces also have only numerical names (i.e. "1", "2", "3", .. etc), then workspace 'zen' will be focused on startup (and in turn, become the i3fyra workspace). Seems i3 interprets 'z' as the first entry of all workspace names defined, with numbers 0-9 tailing behind. It is not - in my experience - the first workspace keybinding defined in i3config. As for me: running I3FYRA_WS=-1 i3fyra --verbose -s A does not work as intended ; same goes for using I3FYRA_WS=4 instead of =-1.

• However, functionally: 'move workspace to next_on_output' seems to be working fine when running i3zen: my workspaces 1-5 are assigned to output1 and workspaces 4-9 are assigned to output2. When using only output1; i3zen will execute correctly and move/create a 'centerzen' window on the 'zen' workspace, as expected. When using multi-monitor setup, however, the 'centerzen' window will be placed on workspace 5 (correctly moving to next_on_output, it seems).

• I hope any of this is in any way useful

• @budRich : I will post the outputs of i3list, i3fyra --verbose, i3king --verbose, my slightly modified i3get/i3info scripts, i3config and i3king rules files etc. if needed or could be helpful in this matter or my observations stated above.

• note that I do use a slightly outdated i3ass , as I can still can't let go of i3menu-rofi in favour of i3menu-dmenu. I have, however, manually edited my i3ass according to updates and issues posted here -- just not i3menu. Also willing to try clean install + reconfigure for further testing, but that could take a while due to busy irl life right now.

[budRich]

@1ntronaut

I hope any of this is in any way useful

Big thanks, this is very good info!

---

I would really like to find and squash these bug(s?).

First thing that is needed is to identify the issues, and find a way to replicate them. And create separate "tickets/issues" for them here on github.

---

I know that one issue, is that the example config file in the wiki has workspace zen listed before the other workspaces, which will make zen the default workspace. I will fix this right away. But reading @1ntronaut tl;dr i see that he believes this is not the case.

There also seem to be an issue with setting the i3fyra workspace, and that i3fyra is (in @sdgoodrick first example) fails because it uses move to workspace $I3FYRA_WS when $I3FYRA_WS="", it should never be empty in this context. It can be that it tries to set it to the active workspace, but the active workspace is somehow the scratchpad?

Related to this is @1ntronaut I3FYRA_WS=..i3FYRA_WS=.. i will grep the source to make sure that lowercase variable isn't used anywhere.

All in all, i think we can group these issues into one, "Manual/Automatic setting which workspace is for i3fyra", I will re-title this issue for that.

---

@1ntronaut

however, autorunning i3fyra -a $layout from i3config does NOT create containers and thus also does not apply the i3fyra layout ; using bindkey for the same command, however, DOES create necessary containers when making floating windows tiled.

Not sure if you have a typo there, but i3fyra -a $layout is wrong, -a|--float will toggle float of current window, it doesn't take arguments. However i3fyra --layout LAYOUT do setup the layout, but it should not create any containers, so i wonder if this isn't working as expected. And the effects you see (when launching with keybinding), containers are created is that you actually toggle from floating to tiled (and therefor create A container)?

Nevertheless, i should add a test in i3fyra and error out if arguments are passed to --float.

---

@1ntronaut

(disregarding the I3FYRA_MAIN_CONTAINER=C set as env variable.)

This is actually something I have noticed myself, I will create a new issue for it.

---

@1ntronaut

additional thoughts:

There are at least three issues here. The first probably relates to the ones described above about i3fyra workspace not being set correctly, but i will create a new issue called "windows spawned from config file, is not placed in i3fyra layout".

And one issue that could be called "i3fyra --move CONTAINER, does not create containers", if you agree, create that issue.

It seems the order in which i3fyra/i3king/i3term are launched could be of significance here

This is a good goalpost for all of these issues, when they are resolved the ordering should not matter. This might also indicate that there is a race condition (where i3fyra is called without I3FYRA_WS being set, multiple time). I will keep it in mind, but let's wait making it a separate issue.

Would using i3term --autotile maybe interfere with assigning i3fyra containers through i3king rules?

Yeah, there is something here and I suspect it boils down to the same thing, a combination of I3FYRA_WS not being set and a race condition from i3fyra trying to automatically set it.

note that I do use a slightly outdated i3ass

It was a bit brutal of me to completely replace/remove i3menu like I did, but, since i3menu now is independent, the obvious fix would be to resurrect the old i3menu, make it a separate repo: i3menu-rofi , doing this will let you (and others, who can't shake rofi) have an up to date i3ass. I will do that, i3menu-rofi will be more or less un-maintained (at least by me) and not recommended, but it can be a thing, sorry that i removed it like that.

[1ntronaut]

@budRich

Not sure if you have a typo there, but i3fyra -a $layout is wrong, -a|--float will toggle float of current window, it doesn't take arguments. However i3fyra --layout LAYOUT do setup the layout, but it should not create any containers, so i wonder if this isn't working as expected. And the effects you see (when launching with keybinding), containers are created is that you actually toggle from floating to tiled (and therefor create A container)?

I am not sure whether or not it's a typo or a brainfart on my part, probably both. Regardless, you are definitely right: i3fyra -a $layout is wrong ; I think I know why I made that mistake:

• I think it stems from way back, even from before bud went from 'Rich' to working in the 'labs', before i3ass' inception

• iirc there was a time when window management through (proto-)i3fyra was done by always floating every window launched ; and subsequently having them tiled through i3config rules with long, chained commands.

• What I did is mix up i3term -a and i3fyra -a, I meant to clarify:

  • does autorunning i3term (esp. autotiled spawns, or configured to be autotiling), maybe interfere with the i3fyra -a float toggle?
  • it seems as if exec/init order is affecting the i3ass-i3fyra-i3term-i3king synergy ; making it more and more likely to botch something along the way, when dealing with our nit-picky, 100% rice-integrated, custom-everything wishes? (don't get me wrong, this birthed i3fyra+i3ass in the first place - not meant to insult in any way)

.... alright, sorry, running out of time here ; will return later.

[budRich]

I made some good progress on this, and found a obvious bug in i3list which made it so that the fyra workspace name was only printed when it was the active workspace. I also made sure that I3FYRA_WS always gets stored with doublequotes, which may or may not have been the reason it was problematic before. (i saw that i did this when the workspace was set automatically to the active workspace name)

[1ntronaut]

I made some good progress on this, and found a obvious bug in i3list which made it so that the fyra workspace name was only printed when it was the active workspace. I also made sure that I3FYRA_WS always gets stored with doublequotes, which may or may not have been the reason it was problematic before. (i saw that i did this when the workspace was set automatically to the active workspace name)

@budRich
Returning from my late shift, I have (now) certainly noticed! Great work!
Thanks a ton, bud. It'll be so satisfying removing this one particular variable from my env/i3env ;p

---

It was a bit brutal of me to completely replace/remove i3menu like I did, but, since i3menu now is independent, the obvious fix would be to resurrect the old i3menu, make it a separate repo: i3menu-rofi , doing this will let you (and others, who can't shake rofi) have an up to date i3ass. I will do that, i3menu-rofi will be more or less un maintained (at least by me) and not recommended, but it can be a thing, sorry that i removed it like that.

@budRich
Thank you for apologizing, bud.. but there's no need for that at all. I trust your judgment/evaluation regarding the switch.
At the same time, you have my sincerest gratitude for re-publishing i3menu-rofi (if only I could read into that single webpage/.html again; I would be able to Fix the font-that-shall-not-be-named, my favourite one ;p ).

Suppose you could 'support' unmaintained i3menu-rofi (at least until it breaks compatibility) and just coin it a deprecated/legacy feature? Maybe introduce another env variable? or command line option? to have i3menu bypass default use of 'dmenu' and use 'rofi' ? (e.g. $I3MENU=dmenu|rofi or i3menu --legacy or whatever). Make it an opt-depend for i3ass install through AUR?
I don't know if these suggestions make much sense, or how much work you'd have to put in to realize this... it's just a thought that came up while writing this reply. Maybe it'll help integration into the entire i3ass suite, and diminish future requests/issues on the topic in the long run?

---

(((-- optional semi-offtopic read:
Truth be told: I've just got too little time on my hands irl to debug+reconfigure+report every config file or script or function that i3ass encompasses on a regular basis. As well as I don't nearly have the knowledge/experience to interpret error messages (or sometimes even my own config) to their full extent. Remember: besides ErikDubois videos helping me understand basic (arch) linux installation ; you were the one that got me into advanced i3wm setup, bash scripting, creating personalized configs for dunst, polybar, rofi, vivaldi and ricing/finetuning my desktop. I'm just glad I can make some pseudo-educated guesses on i3ass etc. from experience, apparently even helpful ones c:
thank you for your teachings and continued effort, mister 2×Thumb --)))

[budRich]

Returning from my late shift

I have been working long days this whole year, which is one, (but not the main), reason i haven't made youtubes in a while. But this week i started my four week vacation, and have some time to tidy up f.i. i3ass

I am actually in the process of resurrecting the budrich blog, i found the original markdown, i will update and publish soon.

But it is just a rewrite of what already been said on ubuntu forums (links still works!)

https://askubuntu.com/questions/210283/how-to-use-fixedsys-in-the-gnome-terminal-or-wherever-monospaced-fonts-are-requ
https://bugs.launchpad.net/ubuntu/+bug/200671

Suppose you could 'support' unmaintained

No, but yes, it will be something like you say. but Neither i3menu(-dmenu) or i3menu-rofi will be included in i3ass again. both will be available as packages on AUR, and in conflict with each other. Only i3menu(-dmenu) will be an optional package for i3ass. So users can always have i3ass installed up to date, and chose if and which i3menu to install. I will maybe try to see (in rofi and i3 community) if someone wants to adopt the i3menu-rofi repository (but i doubt that). i will accept PRs but will not try to fix any issues in i3menu-rofi myself.

I've just got too little time

you and @sdgoodrick have helped out a lot here, and just knowing that there actually exist more than 1 user (bud), made me motivated to do stuff.

you were the one that got me into advanced i3wm setup, bash scripting

❤️