-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bar mode/hidden_state events #2751
Conversation
Like I said on IRC, it can be - you just need sway to be paying attention and let swaybar know over IPC when the button is pressed or released. |
5e69fc7
to
d68bc58
Compare
Functionality is basically all there now, though I may still make small implementation changes. |
57c9709
to
6f8ee6e
Compare
If |
Actually I can't get any of the relevant config options to work without segfaulting sway. |
I fixed mode & hidden_state, I'm not sure about the other ones though. |
The handler structs/selection need to be modified to allow the commands at runtime |
I'm fine with only allowing performing |
Wait how are you actually supposed to confiugre the bar to be hidden until you press mod |
They should be config and runtime
I'll submit a PR to fix it. I think I messed it up during the conversion to subcommands a while ago
I think |
a27e954
to
f3e9d0e
Compare
EDIT: now that the PR has been merged, this patch is no longer required This PR is ready for review
|
I guess I'm probably misunderstanding this but I have no idea how to make this patch have any effect on swaybar. Can someone provide an example config and steps to reproduce the correct behavior? |
I'm a bit confused what you're asking. The patch in the comment is just so you can run As for this PR, it allows using the bar subcommands Example:
hides the bar, but shows it if you press down Mod4 or when there is an urgent workspace.
|
Previously, if a change was sent to all bars, it would only actually change the first bar it encountered, due to return value handling
This adds an id property to the bar, which will be used to filter barconfig_update events
This adds barconfig_update to the list of subscribed events, as well as checking when the other events need to be subscribed to.
This distinguishes the binding mode from the distinct config mode, as well as removing mode_pango_markup from the config struct where it should not be present.
The received json is handled outside of the case statement, which will allow better extensibility. This commit also introduces the variable bar_is_dirty, the return value signifying whether the bar requires rendering.
As well as adding the hidden_state property to the bar config struct, this commit handles barconfig_update events when the mode or hidden_state changes, and uses a new function determine_bar_visibility to hide or show the bar as required, using, respectively, destroy_layer_surface, which is also newly added, and add_layer_surface, which has been changed to allow dynamically adding the surface.
Since wayland does not currently allow swaybar to create global keybinds, this is handled within sway and sent to the bar using a custom event, so as not to pollute existing events, called bar_state_update.
Previously, when the bar was hidden, the height would be set to 0. This meant that if the bar was empty upon reshow, it would not render since the height was still 0, which made it seem there was a problem. Now, the height is not reset, but the width is, to indicate upon reshow that the layer surface needed reconfiguring.
I'm dumb, I was running /usr/bin/swaybar instead of ./swaybar/swaybar |
LGTM, why [WIP]? |
Forgot to change it |
Thanks! |
TODO:
Priority low on this one, it's mostly there but I don't think I will be working that much on it for now.