[i3] i3bar: toggle mode

[justus jonas]

Hi all,

currently I am working on a patch for fixing feature request #651 and
#833. This would introduce a mode "toggle" for i3bar, which toggles
between showing and hiding the i3bar whenever the i3bar modifier is
pressed.

This is easily done when targeting a setup with only one i3bar process.
But when using two bar blocks in the config, two i3bar processes are
started, each one only has knowledge about the output (and its children
workspaces) where they are drawn on. So if one of the bars is unhidden
because of an urgency hint, I have no way to synchronize the
hidden/unhidden state between the two processes. So, when only one of
the bars is unhidden, I would like to react to this in both i3bar
processes, so I can switch to hiding the bars when pressing the modifier
next time. Otherwise the two processes will have different states when
toggling, or I would toggle to unhiding the i3bar even though one or
both of the bars may already be unhidden.

Can anyone of you give me a hint on how to synchronize the state of the
two bars or how to tackle this problem in another way?

Thanks in advance and best regards
jj

[Michael Stapelberg]

Hi justus,

(I like that nickname :-))

Post by justus jonas
currently I am working on a patch for fixing feature request #651 and
#833. This would introduce a mode "toggle" for i3bar, which toggles
between showing and hiding the i3bar whenever the i3bar modifier is
pressed.

You rock! Thanks for all the patches and ongoing work.

Post by justus jonas
Can anyone of you give me a hint on how to synchronize the state of the
two bars or how to tackle this problem in another way?

Here’s an idea:

1) In the bar config, introduce a “hidden” state.
2) Introduce a new i3 command named “bar toggle” (bonus points for also
implementing “bar show” and “bar hide”, they are trivial), that
optionally accepts a parameter, which is the bar id.
3) Users configure e.g. “bindsym $mod+x bar toggle” in their i3 config,
i3 sends the config update with “hidden” as state to all bar
instances (or only the specified one).

The advantages are:
• i3 already provides keybinding configuration, so it should probably go
into i3 anyways
• people can use the IPC interface to do all kinds of specific setup
outside of i3, by using the bar toggle/show/hide command, optionally
with instances.

[Axel Wagner]

Hi all,

basically I like Michael's way, just a few additional questions/thoughts:

How does the manual toggling play together with the autohiding and the
urgency-hint? Because I (obviously) like the way it's done now, in
general, but also would want to take advantage of an explizit hiding or
showing (for example hiding it despite urgency-hints during
presentations, or watch some output of i3bar for a while).
There are a couple of reasonings one could take, which would suggest
different behaviours, I for my reason would like the following, if it is
not too complicated: When mode is hide, do the old autohiding thing, if
sent a „hide“-command, make it hidden (i.e. ignore urgency-hints and
hide-modificator), if sent a „show“-command, make it show (i.e. treat
the hide-modificator as always pressed).

2) Introduce a new i3 command named “bar toggle” (bonus points for also
implementing “bar show” and “bar hide”, they are trivial), that
optionally accepts a parameter, which is the bar id.

For this, imho, there should also (but possibly later in a seperate
patch) be a way to identify the bar in the config. As far as I know, the
identifier currently is a random string generated by i3, but if there
are key-bindings in the i3-config to controll the bars, this is not
sufficient, because it is only know at runtime (is it?).

3) Users configure e.g. “bindsym $mod+x bar toggle” in their i3 config,
i3 sends the config update with “hidden” as state to all bar
instances (or only the specified one).
• i3 already provides keybinding configuration, so it should probably go
into i3 anyways

Again, in the long-run, this could also mean simplifying i3bar by
ripping out all this key-handling-code and have i3 handle that - it
would only be the continuation of that logic. That would mean that (to
make the current behaviour possible) we need to be able to make bindings
on key-press and key-releases.


Well, all that just as general thoughts ;) The latter two have no
immediate significance to this feature, but the first should be decided.

[justus jonas]

Hi,

thanks for the respond, Michael and Axel. I also like the proposed idea
of letting i3 handle the i3bar toggling.

Initially, I thought of a separate toggle mode for i3bar, which would
behave just the same as the hide mode when it comes to unhiding because
of an urgency hint or an activated mode. But it would differ in a sense
that pressing the i3bar modifier would toggle between showing and
hiding, instead of showing on key-press and hiding on key-release. But
what you two said makes sense to me.

As far as I understand Axel's suggestion, we would also need another
command for returning to the original hide mode, as the show command
would unhide the bar by all means, and the hide command would hide the
bar by all means.

The situation for me looks like this:
When in dock mode, every bar command is ignored and everything is
handled like it is now. If in hide mode:
-bar show: always show i3bar, as if the mod was always pressed.
-bar hide: hide the bar and return to normal hide mode, the modifier and
urgency hints unhide the bar.
-bar forcehide: always hide i3bar, until another bar command tells it to
do so.
-bar toggle: this could either cycle through the above mentioned three
variants or it could toggle between "bar show"/"bar hide" or between
"bar show"/"bar forcehide". For my usecases, I would prefer the second
option.

What do you think?

Best
jj

Post by justus jonas
Hi all,
How does the manual toggling play together with the autohiding and the
urgency-hint? Because I (obviously) like the way it's done now, in
general, but also would want to take advantage of an explizit hiding or
showing (for example hiding it despite urgency-hints during
presentations, or watch some output of i3bar for a while).
There are a couple of reasonings one could take, which would suggest
different behaviours, I for my reason would like the following, if it is
not too complicated: When mode is hide, do the old autohiding thing, if
sent a „hide“-command, make it hidden (i.e. ignore urgency-hints and
hide-modificator), if sent a „show“-command, make it show (i.e. treat
the hide-modificator as always pressed).

Post by Michael Stapelberg
2) Introduce a new i3 command named “bar toggle” (bonus points for also
implementing “bar show” and “bar hide”, they are trivial), that
optionally accepts a parameter, which is the bar id.

For this, imho, there should also (but possibly later in a seperate
patch) be a way to identify the bar in the config. As far as I know, the
identifier currently is a random string generated by i3, but if there
are key-bindings in the i3-config to controll the bars, this is not
sufficient, because it is only know at runtime (is it?).

Post by Michael Stapelberg
3) Users configure e.g. “bindsym $mod+x bar toggle” in their i3 config,
i3 sends the config update with “hidden” as state to all bar
instances (or only the specified one).
• i3 already provides keybinding configuration, so it should probably go
into i3 anyways

Again, in the long-run, this could also mean simplifying i3bar by
ripping out all this key-handling-code and have i3 handle that - it
would only be the continuation of that logic. That would mean that (to
make the current behaviour possible) we need to be able to make bindings
on key-press and key-releases.
Well, all that just as general thoughts ;) The latter two have no
immediate significance to this feature, but the first should be decided.

[Axel Wagner]

Post by justus jonas
What do you think?

It makes everything I personally want from it possible, so a big thumbs
up from me for implementing this feature I always wanted but always was
to lazy to build ;)

When I started writing this mail, it came to me, that we can really do
without the force_unhide-mode, which would reduce the
configuration-complexity. If someone (like me) still want the feature,
the simplest thing is to advice them to send i3bar a SIGSTOP when hidden
to force_hide and a SIGCONT to return to normal operation.
Though that may have unintended side-effects (not sure, how well the
process-management works with it, for example) it is probably best to
fix those anyhow.

Hope this helps,

Axel

[Michael Stapelberg]

Hi Axel,

Post by Axel Wagner
the simplest thing is to advice them to send i3bar a SIGSTOP when hidden
to force_hide and a SIGCONT to return to normal operation.
Though that may have unintended side-effects (not sure, how well the
process-management works with it, for example) it is probably best to
fix those anyhow.

Sending i3bar a SIGSTOP is a really bad idea. i3bar really needs to get
the i3 messages from the IPC socket, otherwise i3 locks up.

I am not sure if we can solve this in a good way without having either
buffer management in i3 (to store undeliverable messages) or making IPC
unreliable (dropping messages). I am open for alternatives, but in the
current state, IPC clients must read their messages in a timely matter.

[justus jonas]

Hi Michael,

thanks again for your answer :)

As far as I understand, we would then have a state in the barconfig,
which could be either "show" or "hidden" (and maybe "forcehide"). We
would then switch between the values for toggling. Is there already some
existing code for sending config updates to i3bar, where you could point
me to?

Best
jj

Post by Michael Stapelberg
Hi justus,
(I like that nickname :-))

Post by justus jonas
currently I am working on a patch for fixing feature request #651 and
#833. This would introduce a mode "toggle" for i3bar, which toggles
between showing and hiding the i3bar whenever the i3bar modifier is
pressed.

You rock! Thanks for all the patches and ongoing work.

Post by justus jonas
Can anyone of you give me a hint on how to synchronize the state of the
two bars or how to tackle this problem in another way?

1) In the bar config, introduce a “hidden” state.
2) Introduce a new i3 command named “bar toggle” (bonus points for also
implementing “bar show” and “bar hide”, they are trivial), that
optionally accepts a parameter, which is the bar id.
3) Users configure e.g. “bindsym $mod+x bar toggle” in their i3 config,
i3 sends the config update with “hidden” as state to all bar
instances (or only the specified one).
• i3 already provides keybinding configuration, so it should probably go
into i3 anyways
• people can use the IPC interface to do all kinds of specific setup
outside of i3, by using the bar toggle/show/hide command, optionally
with instances.

[Michael Stapelberg]

Hi justus,

Post by justus jonas
As far as I understand, we would then have a state in the barconfig,

Correct.

Post by justus jonas
would then switch between the values for toggling. Is there already some
existing code for sending config updates to i3bar, where you could point
me to?

There is no code which does that already. I am under the impression that
just sending i3bar an event (without i3bar having requested it) should
do the right thing. Try it and see :-).

[justus jonas]

Hi Michael,

regarding the first version of my uploaded patch for showing/hiding
i3bar through i3, I was thinking about further steps and came to the
conclusion that it might be desirable to fully control hiding and
showing of i3bar through i3. This was already mentioned by Axel Wagner
in a previous post:

"Again, in the long-run, this could also mean simplifying i3bar by
ripping out all this key-handling-code and have i3 handle that - it
would only be the continuation of that logic. That would mean that (to
make the current behaviour possible) we need to be able to make bindings
on key-press and key-releases."

This makes sense to me. Further, I think we could actually also remove
the logic for unhiding because of urgency hints or a newly activated
mode from i3bar. Then either i3 could handle unhiding by initiating a
state update or we could even leave this to ipc scripts, which react to
the corresponding events. In case we would want to this, the "forcehide"
option should actually become a mode, and we should reduce the state to
only have the options "hide" and "show". So, the mode "forcehide" in
i3bar would just ignore state updates when it comes to unhiding or
showing the bar. Additionally, if i3 fully controls the state of the
i3bar instances, the state in the barconfig always really reflects the
actual state of the bar (currently i3 does not know about an internal
unhiding initiated by i3bar itself).

For this to work, we would need the following:
(1) Like Axel said, we would need the possibility to react to keypress
and keyrelease separately and would need to overload a key, so I could
use windows-key as bar modifier and still use keybinding like windows+h.
(2) With the new event for sending barconfig updates, it would be easy
to add a possibility to switch modes on the fly (also demanded in
feature request #651). This would then make it possible, to switch to
the new "forcehide" mode.

So the current hide-behaviour of i3bar using the barmodifier could be
configured like this:
bindsym $mod bar show
bindsym --release $mod bar hide

The only difference here would be that the bar modifier would need to be
specifically defined within a binding-mode. To me, this even sounds like
the more consistent approach.

What do you think?

Best regards and thanks to you (and all contributors) for this wonderful wm
jj

Post by Michael Stapelberg
Hi justus,

Post by justus jonas
As far as I understand, we would then have a state in the barconfig,

Correct.

Post by justus jonas
would then switch between the values for toggling. Is there already some
existing code for sending config updates to i3bar, where you could point
me to?

There is no code which does that already. I am under the impression that
just sending i3bar an event (without i3bar having requested it) should
do the right thing. Try it and see :-).

[Michael Stapelberg]

Hi justus,

Post by justus jonas
(1) Like Axel said, we would need the possibility to react to keypress
and keyrelease separately and would need to overload a key, so I could
use windows-key as bar modifier and still use keybinding like
windows+h.

See http://bugs.i3wm.org/query/ticket/386 for binding just a modifier
(combination). It could be as simple as changing the config file parser,
but I haven’t tested that.

Post by justus jonas
(2) With the new event for sending barconfig updates, it would be easy
to add a possibility to switch modes on the fly (also demanded in
feature request #651). This would then make it possible, to switch to
the new "forcehide" mode.

I think #651 is well handled with your current patch already. Am I
missing something?

Post by justus jonas
So the current hide-behaviour of i3bar using the barmodifier could be
bindsym $mod bar show
bindsym --release $mod bar hide

You do realize that bindsym --release does exist, right? It even works,
but I’m not sure if this specific case is handled.

[justus jonas]

Hi,

Post by Michael Stapelberg
Hi justus,

Post by justus jonas
(1) Like Axel said, we would need the possibility to react to keypress
and keyrelease separately and would need to overload a key, so I could
use windows-key as bar modifier and still use keybinding like
windows+h.

See http://bugs.i3wm.org/query/ticket/386 for binding just a modifier
(combination). It could be as simple as changing the config file parser,
but I haven’t tested that.

sounds doable. I could look into that.

Post by Michael Stapelberg

Post by justus jonas
(2) With the new event for sending barconfig updates, it would be easy
to add a possibility to switch modes on the fly (also demanded in
feature request #651). This would then make it possible, to switch to
the new "forcehide" mode.

I think #651 is well handled with your current patch already. Am I
missing something?

as I understand the request, this is different from showing the bar
overlaying the visible window on the bottom of the ws (just like holding
down the modifier while in hide mode). It says that it should be
possible to switch between dock and hide mode.

Post by Michael Stapelberg

Post by justus jonas
So the current hide-behaviour of i3bar using the barmodifier could be
bindsym $mod bar show
bindsym --release $mod bar hide

You do realize that bindsym --release does exist, right? It even works,
but I’m not sure if this specific case is handled.

ok, thanks for the hint, I overlooked that it already existed.

Best
jj

[justus jonas]

Just tried out the --release parameter, it works for pressing the key
for a short period of time. But when pressing the bound keys for a
longer time (like 2 seconds), the keypress and keyrelease commands are
executed multiple times in a row for as long as I press the keys. Is
this intended?

I had this configured:
bindsym $mod+u bar show
bindsym --release $mod+u bar hide

Post by justus jonas
Hi,

Post by Michael Stapelberg
Hi justus,

Post by justus jonas
(1) Like Axel said, we would need the possibility to react to keypress
and keyrelease separately and would need to overload a key, so I could
use windows-key as bar modifier and still use keybinding like windows+h.

See http://bugs.i3wm.org/query/ticket/386 for binding just a modifier
(combination). It could be as simple as changing the config file parser,
but I haven’t tested that.

sounds doable. I could look into that.

Post by Michael Stapelberg

Post by justus jonas
(2) With the new event for sending barconfig updates, it would be easy
to add a possibility to switch modes on the fly (also demanded in
feature request #651). This would then make it possible, to switch to
the new "forcehide" mode.

I think #651 is well handled with your current patch already. Am I
missing something?

as I understand the request, this is different from showing the bar
overlaying the visible window on the bottom of the ws (just like holding
down the modifier while in hide mode). It says that it should be
possible to switch between dock and hide mode.

Post by Michael Stapelberg

Post by justus jonas
So the current hide-behaviour of i3bar using the barmodifier could be
bindsym $mod bar show
bindsym --release $mod bar hide

You do realize that bindsym --release does exist, right? It even works,
but I’m not sure if this specific case is handled.

ok, thanks for the hint, I overlooked that it already existed.
Best
jj

[Michael Stapelberg]

Hi justus,

Post by justus jonas
Just tried out the --release parameter, it works for pressing the key
for a short period of time. But when pressing the bound keys for a
longer time (like 2 seconds), the keypress and keyrelease commands are
executed multiple times in a row for as long as I press the keys. Is
this intended?

Of course not. But check with xev(1) whether the key is triggered
multiple times.

Post by justus jonas

Post by justus jonas

Post by Michael Stapelberg

Post by justus jonas
(2) With the new event for sending barconfig updates, it would be easy
to add a possibility to switch modes on the fly (also demanded in
feature request #651). This would then make it possible, to switch to
the new "forcehide" mode.

I think #651 is well handled with your current patch already. Am I
missing something?

as I understand the request, this is different from showing the bar
overlaying the visible window on the bottom of the ws (just like holding
down the modifier while in hide mode). It says that it should be
possible to switch between dock and hide mode.

Fair enough.

[justus jonas]

Hi Michael,

Post by Michael Stapelberg
Hi justus,

Post by justus jonas
Just tried out the --release parameter, it works for pressing the key
for a short period of time. But when pressing the bound keys for a
longer time (like 2 seconds), the keypress and keyrelease commands are
executed multiple times in a row for as long as I press the keys. Is
this intended?

Of course not. But check with xev(1) whether the key is triggered
multiple times.

It is triggered multiple times. Keeping on pressing any key for some
time does toggle between sending the keyrelease and keypress event for
as long as the key is pressed. But it would actually be nice if it would
be possible that the command was executed only once per keydown/up.

Post by Michael Stapelberg

Post by justus jonas

Post by justus jonas

Post by Michael Stapelberg

Post by justus jonas
(2) With the new event for sending barconfig updates, it would be easy
to add a possibility to switch modes on the fly (also demanded in
feature request #651). This would then make it possible, to switch to
the new "forcehide" mode.

I think #651 is well handled with your current patch already. Am I
missing something?

as I understand the request, this is different from showing the bar
overlaying the visible window on the bottom of the ws (just like holding
down the modifier while in hide mode). It says that it should be
possible to switch between dock and hide mode.

Fair enough.

Best
Johannes

[Bas Pape]

Post by Michael Stapelberg
Hi justus,

Post by justus jonas
Just tried out the --release parameter, it works for pressing the key
for a short period of time. But when pressing the bound keys for a
longer time (like 2 seconds), the keypress and keyrelease commands are
executed multiple times in a row for as long as I press the keys. Is
this intended?

Of course not. But check with xev(1) whether the key is triggered
multiple times.

Regular key-repeat applies, so with the given example config, you'd
get a ton of u with the flag for $mod set. Modifiers on their own
don't repeat (except for Multi_Key, apparently). I'd say this is
expected/acceptable behaviour; assuming keybinds for just modifiers
just work, this would not affect the "current hide-behaviour of i3bar
using the barmodifier" part either.

--
Tucos

[justus jonas]

Hi Tucos,

thanks for clearing that up. Sounds indeed acceptable then; so never
mind what I said.

Post by Bas Pape

Post by Michael Stapelberg
Hi justus,

Post by justus jonas
Just tried out the --release parameter, it works for pressing the key
for a short period of time. But when pressing the bound keys for a
longer time (like 2 seconds), the keypress and keyrelease commands are
executed multiple times in a row for as long as I press the keys. Is
this intended?

Of course not. But check with xev(1) whether the key is triggered
multiple times.

Regular key-repeat applies, so with the given example config, you'd
get a ton of u with the flag for $mod set. Modifiers on their own
don't repeat (except for Multi_Key, apparently). I'd say this is
expected/acceptable behaviour; assuming keybinds for just modifiers
just work, this would not affect the "current hide-behaviour of i3bar
using the barmodifier" part either.
--
Tucos

[justus jonas]

Hi Michael,

we previously discussed a patch for controlling the hidden state of
i3bar through an i3 command. With this working, we could also define the
bar_modifier as a bindsym command. I did not have time to work on a full
patch for binding just modifier keys so far, but tried out some stuff.
Thereby, I discovered the following problem with this approach:

When pressing a defined keybinding, the click events of the mouse are
not send to the focused window until the keybinding is released. This
causes a problem when trying to show i3bar by pressing a key and hiding
it again by releasing the key. So, trying to click, e.g., on a tray icon
would not work, as the click event is send to i3bar just after the
keybinding was released. Any suggestions on how to solve this?

Best
jj

Post by Michael Stapelberg
Hi justus,

Post by justus jonas
(1) Like Axel said, we would need the possibility to react to keypress
and keyrelease separately and would need to overload a key, so I could
use windows-key as bar modifier and still use keybinding like
windows+h.

See http://bugs.i3wm.org/query/ticket/386 for binding just a modifier
(combination). It could be as simple as changing the config file parser,
but I haven’t tested that.

Post by justus jonas
(2) With the new event for sending barconfig updates, it would be easy
to add a possibility to switch modes on the fly (also demanded in
feature request #651). This would then make it possible, to switch to
the new "forcehide" mode.

I think #651 is well handled with your current patch already. Am I
missing something?

Post by justus jonas
So the current hide-behaviour of i3bar using the barmodifier could be
bindsym $mod bar show
bindsym --release $mod bar hide

You do realize that bindsym --release does exist, right? It even works,
but I’m not sure if this specific case is handled.