[i34wm] i3monocle [request]

1ntronaut commented

2025-08-15 09:08:39 +00:00

(Migrated from github.com)

I want to be able to have a hotkey shortcut to toggle a monocle mode, hiding all non-focused i3frya containers. This way, I can have a alternative to fullscreen mode, but keep my status bar (currently polybar) visible .

Ex. if i3fyra family is AC/BD (default) and Container C is focused: hide containers A, B and D.

@budRich Is this attainable inside i3fyra itself (e.g. i3monocle or i3fyra --mono?

Tried testing, but the container hiding doesn't work properly and below script keeps giving inconsistent results, what gives?

#!/usr/bin/env bash

declare -A i3list
eval "$(i3list)"

## hide i3fyra container 'twin', 'cousin' and 'sibling'
i3fyra --hide ${i3list[AFT]} && \
i3fyra --hide ${i3list[AFC]} && \
i3fyra --hide ${i3list[AFS]}

notify-send "i3fyra --hide ${i3list[AFT]}${i3list[AFT]}${i3list[AFS]}" "Monocle current container"
exit

P.S. notify-send returns:

i3fyra --hide DDA
Monocle current container

I want to be able to have a hotkey shortcut to toggle a monocle mode, hiding all non-focused i3frya containers. This way, I can have a alternative to fullscreen mode, but keep my status bar (currently polybar) visible . Ex. if i3fyra family is AC/BD (default) and Container C is focused: hide containers A, B and D. @budRich Is this attainable _inside_ i3fyra itself (e.g. `i3monocle` or `i3fyra --mono`? Tried testing, but the container hiding doesn't work properly and below script keeps giving inconsistent results, what gives? ```bash #!/usr/bin/env bash declare -A i3list eval "$(i3list)" ## hide i3fyra container 'twin', 'cousin' and 'sibling' i3fyra --hide ${i3list[AFT]} && \ i3fyra --hide ${i3list[AFC]} && \ i3fyra --hide ${i3list[AFS]} notify-send "i3fyra --hide ${i3list[AFT]}${i3list[AFT]}${i3list[AFS]}" "Monocle current container" exit ``` P.S. notify-send returns: > i3fyra --hide DDA > Monocle current container

👍 1

budRich commented

2025-09-27 10:56:30 +00:00

(Migrated from github.com)

Interesting. I remember vaguely, i had similar ideas when i initially wrote the --hide functionality, and that i then made sure that it would work properly to multihide containers, just for this purpose. But i never really used it myself, and it is very possible that the multihide functionality has become broken.

I will look into this. i have a feeling solving this issue will solve other known or unkown issues as well.

I do like the --mono option name.

...

i did some quick testing in the terminal. and something weird is going on. when i just do i3list, it spits out the array and i can see that value of i3list[AFS]=A , but when i eval $(i3list), and do echo ${i3list[AFS]} , it prints container ID of active container. and does the same thing for AFO... hmmmmm

aha, first declare -A i3list .

this actually works fine for me, at least from a terminal. i3fyra --hide ADB , hides all but C container, and hide BD as a family.

I will test with a script also

Interesting. I remember vaguely, i had similar ideas when i initially wrote the --hide functionality, and that i then made sure that it would work properly to multihide containers, just for this purpose. But i never really used it myself, and it is very possible that the multihide functionality has become broken. I will look into this. i have a feeling solving this issue will solve other known or unkown issues as well. I do like the `--mono` option name. ... ~~i did some quick testing in the terminal. and something weird is going on. when i just do i3list, it spits out the array and i can see that value of i3list[AFS]=A , but when i eval $(i3list), and do echo ${i3list[AFS]} , it prints container ID of active container. and does the same thing for AFO... hmmmmm~~ aha, first declare -A i3list . this actually works fine for me, at least from a terminal. i3fyra --hide ADB , hides all but C container, and hide BD as a family. I will test with a script also

budRich commented

2025-09-27 11:09:43 +00:00

(Migrated from github.com)

notify-send "i3fyra --hide ${i3list[AFT]}${i3list[AFT]}${i3list[AFS]}" "Monocle current container"

^ this will, as you say print i3fyra --hide DDA , since there is two AFT

Hiding seem to work fine and reliable for me, can you reproduce a scenario where you get inconsistent results?

>`notify-send "i3fyra --hide ${i3list[AFT]}${i3list[AFT]}${i3list[AFS]}" "Monocle current container"` ^ this will, as you say print i3fyra --hide DDA , since there is two AFT --- Hiding seem to work fine and reliable for me, can you reproduce a scenario where you get inconsistent results?

budRich commented

2025-09-27 11:27:29 +00:00

(Migrated from github.com)

try this:

#!/bin/bash

declare -A i3list
eval "$(i3list)"

current_container=${i3list[AWP]}

((i3list[WSA] == i3list[WSF])) || {
  notify-send "mono operation only possible on with i3fyra workspace"
  exit
}

number_of_visible_containers=${#i3list[LVI]}

((number_of_visible_containers < 2)) && {
  existing_containers=${i3list[LEX]}
  existing_others=${existing_containers/$current_container/}
  i3fyra --show "$existing_others"
  exit
}

visible_containers=${i3list[LVI]}
visible_others=${visible_containers/$current_container}

i3fyra --hide "${visible_others}"

try this: ```bash #!/bin/bash declare -A i3list eval "$(i3list)" current_container=${i3list[AWP]} ((i3list[WSA] == i3list[WSF])) || { notify-send "mono operation only possible on with i3fyra workspace" exit } number_of_visible_containers=${#i3list[LVI]} ((number_of_visible_containers < 2)) && { existing_containers=${i3list[LEX]} existing_others=${existing_containers/$current_container/} i3fyra --show "$existing_others" exit } visible_containers=${i3list[LVI]} visible_others=${visible_containers/$current_container} i3fyra --hide "${visible_others}" ```

budRich commented

2025-09-27 11:32:01 +00:00

(Migrated from github.com)

above script will either hide all other containers, or if there is only one container, same script will show all other containers. maybe it is even possible to fine tune it further, so that if f.i. aCd are visible, and B is already hidden when we trigger mono. if we trigger mono again, it should not bring back B, i think that is possible too, with the memory variables in i3list..

budRich commented

2025-09-27 12:30:33 +00:00

(Migrated from github.com)

ok, i add --mono to i3fyra , @1ntronaut see if you can break it.
#2279c7c

ok, i add `--mono` to i3fyra , @1ntronaut see if you can break it. [#2279c7c](https://github.com/budlabs/i3ass/commit/2279c7cd468ed47bd074e6e17779f1e69e9b4890)

budRich commented

2025-09-27 12:32:22 +00:00

(Migrated from github.com)

i did some manipulation of how the "family memory" is stored, so it now changes when we hide a single container (previously it only changed when a whole family was hidden). This make it somewhat reliable to toggle --mono back and forth. But it may or may not break other things, i have tried to break it but it seems to work..

budRich commented

2025-09-28 12:07:53 +00:00

(Migrated from github.com)

i knew there was something to be found. There was a bug in how i3fyra variables (split memory and such) are stored, which sometimes lead to duplicate variables being created. I patched it, and i bet this was a cause of other known and unkown issues.

1ntronaut commented

2025-10-17 14:54:41 +00:00

(Migrated from github.com)

i knew there was something to be found. There was a bug in how i3fyra variables (split memory and such) are stored, which sometimes lead to duplicate variables being created. I patched it, and i bet this was a cause of other known and unkown issues.

Haven't had time to test the new code yet, but thank you @budRich. I have the suspicion this could also fix windows returning to their assigned i3fyra containers, even when they have moved around.
So, for example: I have instance 'mainterm' assigned to tile in container A, but when I move the entire container A to the location of C and vice versa (by pressing: $mod+shift+K and then $mod+shift+J), such that 'mainterm' is now in container C. If I now manually float 'mainterm' and tile it again, it will move to container C, in stead of container A (as is assigned and handled by i3king)... But I'll test this usecase for sure, when I find the time..

> i knew there was something to be found. There was a bug in how i3fyra variables (split memory and such) are stored, which sometimes lead to duplicate variables being created. I patched it, and i bet this was a cause of other known and unkown issues. Haven't had time to test the new code yet, but thank you @budRich. I have the suspicion this could also fix windows returning to their _assigned_ i3fyra containers, even when they have moved around. So, for example: I have instance 'mainterm' assigned to tile in container A, but when I move the entire container A to the location of C and vice versa (by pressing: $mod+shift+K and then $mod+shift+J), such that 'mainterm' is now in container C. If I now manually float 'mainterm' and tile it again, it will move to container C, in stead of container A (as is assigned and handled by i3king)... But I'll test this usecase for sure, when I find the time..

1ntronaut commented

2025-10-17 15:00:03 +00:00

(Migrated from github.com)

above script will either hide all other containers, or if there is only one container, same script will show all other containers. maybe it is even possible to fine tune it further, so that if f.i. aCd are visible, and B is already hidden when we trigger mono. if we trigger mono again, it should not bring back B, i think that is possible too, with the memory variables in i3list..

Additionally, I realize, now that you mentioned it, that this is indeed the behaviour I have come across when using i3fyra, where I have to manually rearrange/hide a container again in one (or two) families.. It was never too much effort or significant in breaking my workflow window management, but I do recognize exactly what you mean.

> above script will either hide all other containers, or if there is only one container, same script will show all other containers. maybe it is even possible to fine tune it further, so that if f.i. aCd are visible, and B is already hidden when we trigger mono. if we trigger mono again, it should not bring back B, i think that is possible too, with the memory variables in i3list.. Additionally, I realize, now that you mentioned it, that this is indeed the behaviour I have come across when using i3fyra, where I have to manually rearrange/hide a container again in one (or two) families.. It was never too much effort or significant in breaking my workflow window management, but I _do_ recognize exactly what you mean.

1ntronaut commented

2025-12-27 10:27:23 +00:00

(Migrated from github.com)

ok, i add --mono to i3fyra , @1ntronaut see if you can break it. #2279c7c

Dear Bud, it's me again...
--mono works like a charm

Please consider short optino i3fyra -M for toggling monocle mode
Otheriwse, close issue, thank you so much!

> ok, i add `--mono` to i3fyra , [@1ntronaut](https://github.com/1ntronaut) see if you can break it. [#2279c7c](https://github.com/budlabs/i3ass/commit/2279c7cd468ed47bd074e6e17779f1e69e9b4890) Dear Bud, it's me again... `--mono` works like a charm Please consider short optino `i3fyra -M` for toggling monocle mode Otheriwse, close issue, thank you so much!

budRich commented

2025-12-27 10:53:19 +00:00

(Migrated from github.com)

Yeah, i have used this feature myself quite a bit more than i expected to do, and have not noticed any issues, i will try to wrap up a new release this weekend and will include short opt -M

Yeah, i have used this feature myself quite a bit more than i expected to do, and have not noticed any issues, i will try to wrap up a new release this weekend and will include short opt `-M`

1ntronaut commented

2025-12-27 10:54:48 +00:00

(Migrated from github.com)

Yeah, i have used this feature myself quite a bit more than i expected to do, and have not noticed any issues, i will try to wrap up a new release this weekend and will include short opt -M

Bud, I was typing a big edit, where I found some issues w/ --mono, but because of you replying, the page updated and now my draft post is gone xd

> Yeah, i have used this feature myself quite a bit more than i expected to do, and have not noticed any issues, i will try to wrap up a new release this weekend and will include short opt `-M` Bud, I was typing a big edit, where I found some issues w/ --mono, but because of you replying, the page updated and now my draft post is gone xd

1ntronaut commented

2025-12-27 11:23:23 +00:00

(Migrated from github.com)

Hiya @budRich ,

Installed freshly pulled source from git.

Monocle mode works like a charm, including the short option -M, none of the earlier bugs I found apply anymore..

Only one tiny thing remains:

When invoking i3fyra --mono from a floating container, it will hide ALL regular (tiled) containers on the i3fyra workspace. Toggling i3fyra --mono again will SHOW them all in exactly the same layout/order as they were before

otherwise, consider i3monocle a success

Hiya @budRich , Installed freshly pulled source from git. Monocle mode works like a charm, including the short option -M, none of the earlier bugs I found apply anymore.. Only one tiny thing remains: 1) When invoking `i3fyra --mono` from a floating container, it will hide ALL regular (tiled) containers on the i3fyra workspace. Toggling `i3fyra --mono` again will SHOW them all in exactly the same layout/order as they were before otherwise, consider `i3monocle` a success

budRich commented

2025-12-27 11:54:31 +00:00

(Migrated from github.com)

Ah, don't think i ever considered floating windows. It doesn't work properly at all here. When I toggle floating just as you describe it hides all tiled windows, but when i toggle back it bring back the windows, but for me the layout is all messed up.

Not sure exectly how i would like it to work, it might sound obvious for monocle on a floating window to hide all other windows and tile the floating window to make it monocled on the workspace. but, now where does this window belong if we toggle --mono back? either make it tabbed/tiled in the last focused fyra container. Or make the window floating again and bring back the old windows. yeah, i think that is what should happen i will experiment with this a bit.

Ah, don't think i ever considered floating windows. It doesn't work properly at all here. When I toggle floating just as you describe it hides all tiled windows, but when i toggle back it bring back the windows, but for me the layout is all messed up. Not sure exectly how i would like it to work, it might sound obvious for monocle on a floating window to hide all other windows and tile the floating window to make it monocled on the workspace. but, now where does this window belong if we toggle --mono back? either make it tabbed/tiled in the last focused fyra container. Or make the window floating again and bring back the old windows. yeah, i think that is what should happen i will experiment with this a bit.

budRich commented

2025-12-27 14:42:24 +00:00

(Migrated from github.com)

I found another bug! Apparently when multiple containers spanning multiple families where shown, i3fyra created the main layout container multiple times, i think i have fixed that now. Regarding floating -> monocle i desided on this:

if active window is floating i think what we want is
for it to be tiled in a container and hide all other
containers. if no container exist, we toggle floating
else we send it to first found container (prio VIS)
and hide all others.
it gets a bit weird when we toggle back from monocled
with such a window, in one way it would make sense
to make it floating again, on the other hand, it might
feel awkward if user has forgotten that it was once
floating->monocled (time can in some cases be days or weeks...)
so i think we should just let it be tiled, and show the other
containers. if user wants it floating again they manually toggle float
one could argue that we should also have the user manually tile window
before entering monocle, but this will make it un-intuitive, since no action
except error message (that is hard to find when triggered with keybinding) will be shown in such casem with this approach something will most likely happen every time --mono is used (on a i3fyra workspace).

just realized that maybe if we are not on i3fyra workspace we could just toggle normal full screen?

I found another bug! Apparently when multiple containers spanning multiple families where shown, i3fyra created the main layout container multiple times, i think i have fixed that now. Regarding floating -> monocle i desided on this: if active window is floating i think what we want is for it to be tiled in a container and hide all other containers. if no container exist, we toggle floating else we send it to first found container (prio VIS) and hide all others. it gets a bit weird when we toggle back from monocled with such a window, in one way it would make sense to make it floating again, on the other hand, it might feel awkward if user has forgotten that it was once floating->monocled (time can in some cases be days or weeks...) so i think we should just let it be tiled, and show the other containers. if user wants it floating again they manually toggle float one could argue that we should also have the user manually tile window before entering monocle, but this will make it un-intuitive, since no action except error message (that is hard to find when triggered with keybinding) will be shown in such casem with this approach *something* will most likely happen every time --mono is used (on a i3fyra workspace). just realized that maybe if we are not on i3fyra workspace we could just toggle normal full screen?

Rows
Columns

[i34wm] i3monocle [request] #225