Re: [i3] i3bar: toggle mode
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 Am 17.04.2013 20:32, schrieb Michael Stapelberg: Hi justus, justus jonas hap...@web.de writes: 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. 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. (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? So the current hide-behaviour of i3bar using the barmodifier could be configured like this: 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.
Re: [i3] i3bar: toggle mode
Hi justus, justus jonas hap...@web.de writes: 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. 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. (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? So the current hide-behaviour of i3bar using the barmodifier could be configured like this: 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. -- Best regards, Michael
Re: [i3] i3bar: toggle mode
Hi, Am 17.04.2013 20:32, schrieb Michael Stapelberg: Hi justus, justus jonas hap...@web.de writes: 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. 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. (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. So the current hide-behaviour of i3bar using the barmodifier could be configured like this: 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
Re: [i3] i3bar: toggle mode
Hi Tucos, thanks for clearing that up. Sounds indeed acceptable then; so never mind what I said. Am 17.04.2013 22:59, schrieb Bas Pape: 2013/4/17 Michael Stapelberg mich...@i3wm.org: Hi justus, justus jonas hap...@web.de writes: 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
Re: [i3] i3bar: toggle mode
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 :-).
[i3] i3bar: toggle mode
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
Re: [i3] i3bar: toggle mode
Hi justus, (I like that nickname :-)) justus jonas hap...@web.de writes: 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. 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. -- Best regards, Michael
Re: [i3] i3bar: toggle mode
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 Am 13.04.2013 16:29, schrieb 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). Excerpts from Michael Stapelberg's message of 2013-04-13 15:59:14 +0200: 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). The advantages are: • 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.
Re: [i3] i3bar: toggle mode
Excerpts from justus jonas's message of 2013-04-13 18:24:00 +0200: 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 signature.asc Description: PGP signature
Re: [i3] i3bar: toggle mode
Hi Axel, Axel Wagner m...@merovius.de writes: 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. -- Best regards, Michael
Re: [i3] i3bar: toggle mode
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 Am 13.04.2013 15:59, schrieb Michael Stapelberg: Hi justus, (I like that nickname :-)) justus jonas hap...@web.de writes: 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. 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.
Re: [i3] i3bar: toggle mode
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 :-). -- Best regards, Michael
