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
Am 13.04.2013 21:30, schrieb Michael Stapelberg:
Hi justus,
justus jonas <hap...@web.de> writes:
As far as I understand, we would then have a state in the barconfig,
Correct.
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 :-).
