[i3fyra] Manual/Automatic initialization of I3FYRA_WS is broken #180
Labels
No labels
Arch PKGBUILD
bug
build
commandline
duplicate
enhancement
font
good first issue
help wanted
implemented
is-it-really-a-bug?
necromancy
not-reproducable
question
reproducable
rofi
solved?
stalled
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
bud/i3ass#180
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
I will look through the script myself and try to debug this, but any insight would be appreciated
@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.aha!
m [con_id=94277602805984] floating disable, move --no-auto-back-and-forth to workspacethere is no workspace target.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_wsOne 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 AI'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 havei3list[WFN]set.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 thezenworkspaceHere's something, interesting: after rebooting and running
i3fyra -a, I do get those variables set:and now i3fyra almost works? I get a new error from
i3fyra --verbose -s A:i3fyra_wsis still\, butI3FYRA_WS=-1 i3fyra --verbose -s Adoes seem to work now!!!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 1before you have a keybinding taking you to zen.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 4run through my i3config, BEFORE setting the 'layout' variable for i3fyra's layout.however, autorunning
i3fyra -a $layoutfrom 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=Cset as env variable.)i3viswizwindow 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.i3list[RED]as well as stored splitsi3list[MAB,MAC,MBD].additional thoughts:
i3infoscript, as well as startingi3king --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 --floatthese windows twice (creating the 'A' container) and manuallyi3viswiz l|d|u|rthem 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|Ddoes NOT.. and also won't move windows to containers if I don'ti3viswizmove them manually to create ABCD containers beforehand.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/i3termare 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 --autotilemaybe 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: runningI3FYRA_WS=-1 i3fyra --verbose -s Adoes not work as intended ; same goes for usingI3FYRA_WS=4instead 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,i3configand i3kingrulesfiles 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.
@1ntronaut
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 zenlisted 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_WSwhen$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
Not sure if you have a typo there, but
i3fyra -a $layoutis wrong,-a|--floatwill toggle float of current window, it doesn't take arguments. Howeveri3fyra --layout LAYOUTdo 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
This is actually something I have noticed myself, I will create a new issue for it.
@1ntronaut
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.
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.
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.
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
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 $layoutis wrong ; I think I know why I made that mistake:I think it stems from way back, even from before
budwent from 'Rich' to working in the 'labs', before i3ass' inceptioniirc 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 -aandi3fyra -a, I meant to clarify:i3term(esp. autotiled spawns, or configured to be autotiling), maybe interfere with thei3fyra -afloat toggle?.... alright, sorry, running out of time here ; will return later.
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
@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
Fixthe 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|rofiori3menu --legacyor 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 --)))
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
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.
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.
❤️