Re: [i3] i3bar: toggle mode
Hi justus, justus jonas 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
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 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 Axel, Axel Wagner 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
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, 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] i3lock hooks
On 2013-04-13 10:14, Michael Stapelberg wrote:
>Giorgos Keramidas writes:
>> After ev_loop() is done, there is no return statement, so if ev_loop
>> happens to return, main() is free to return a random value, e.g. the
>> contents of a register or some random value from the stack.
>
> ev_loop never returns.
>
> i3lock exits with code 0 from here:
>
> if (pam_authenticate(pam_handle, 0) == PAM_SUCCESS) {
> DEBUG("successfully authenticated\n");
> clear_password_memory();
> exit(0);
> }
Yeah, I noticed that ev_loop is not supposed to return a little after
sending that email. I guess the only way to find out what's going on
would be to run i3lock under strace and log that to a file.
If ev_loop never returns, I don't see anything in i3lock.c that would
cause it to return with a non-zero exit code. It must be something
external to the program itself, e.g. a signal that's killing it.
Re: [i3] i3bar: toggle mode
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. signature.asc Description: PGP signature
Re: [i3] i3bar: toggle mode
Hi justus, (I like that nickname :-)) justus jonas 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
[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] i3lock hooks
Hi Giorgos,
Giorgos Keramidas writes:
> After ev_loop() is done, there is no return statement, so if ev_loop
> happens to return, main() is free to return a random value, e.g. the
> contents of a register or some random value from the stack.
ev_loop never returns.
i3lock exits with code 0 from here:
if (pam_authenticate(pam_handle, 0) == PAM_SUCCESS) {
DEBUG("successfully authenticated\n");
clear_password_memory();
exit(0);
}
--
Best regards,
Michael
