Skip to content
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

Merged
merged 14 commits into from
Oct 14, 2018
Merged

Bar mode/hidden_state events #2751

merged 14 commits into from
Oct 14, 2018

Conversation

ianyfan
Copy link
Contributor

@ianyfan ianyfan commented Oct 2, 2018

TODO:

  • send stop/start signals to status
  • key events - cannot be done using current layer shell protocol due to focus issues, may need a new protocol or IPC event
  • show bar on workspace urgency
  • documentation

Priority low on this one, it's mostly there but I don't think I will be working that much on it for now.

@ddevault
Copy link
Contributor

ddevault commented Oct 2, 2018

key events - cannot be done using current layer shell protocol due to focus issues, may need a new protocol or IPC event

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.

@ianyfan ianyfan force-pushed the swaybar branch 2 times, most recently from 5e69fc7 to d68bc58 Compare October 8, 2018 16:48
@ianyfan ianyfan changed the title [WIP] Bar mode/hidden_state events Bar mode/hidden_state events Oct 8, 2018
@ianyfan
Copy link
Contributor Author

ianyfan commented Oct 8, 2018

Functionality is basically all there now, though I may still make small implementation changes.

@ianyfan ianyfan force-pushed the swaybar branch 2 times, most recently from 57c9709 to 6f8ee6e Compare October 8, 2018 16:56
@ddevault
Copy link
Contributor

ddevault commented Oct 9, 2018

If hidden_state is executed in the config file, sway segfaults

@ddevault
Copy link
Contributor

ddevault commented Oct 9, 2018

Actually I can't get any of the relevant config options to work without segfaulting sway.

@ianyfan
Copy link
Contributor Author

ianyfan commented Oct 9, 2018

I fixed mode & hidden_state, I'm not sure about the other ones though.

@ianyfan ianyfan mentioned this pull request Oct 9, 2018
@RedSoxFan
Copy link
Member

The handler structs/selection need to be modified to allow the commands at runtime

@ianyfan
Copy link
Contributor Author

ianyfan commented Oct 9, 2018

I'm fine with only allowing performing mode and hidden_state commands at runtime, though there's a bug with that currently: #2791 (comment)

@ddevault
Copy link
Contributor

ddevault commented Oct 9, 2018

Wait how are you actually supposed to confiugre the bar to be hidden until you press mod

@RedSoxFan
Copy link
Member

I'm fine with only allowing performing mode and hidden_state commands at runtime

They should be config and runtime

though there's a bug with that currently: #2791 (comment)

I'll submit a PR to fix it. I think I messed it up during the conversion to subcommands a while ago

Wait how are you actually supposed to confiugre the bar to be hidden until you press mod

I think bar mode hide [<bar-id>] is what you are looking for

@ianyfan ianyfan changed the title Bar mode/hidden_state events [WIP] Bar mode/hidden_state events Oct 10, 2018
@ianyfan ianyfan force-pushed the swaybar branch 3 times, most recently from a27e954 to f3e9d0e Compare October 13, 2018 11:04
@ianyfan
Copy link
Contributor Author

ianyfan commented Oct 13, 2018

EDIT: now that the PR has been merged, this patch is no longer required

This PR is ready for review , though until #2808 is merged, this requires a patch in order to test changing mode/state at runtime:

diff --git a/sway/commands/bar.c b/sway/commands/bar.c
index 03f4c557..b0733452 100644
--- a/sway/commands/bar.c
+++ b/sway/commands/bar.c
@@ -46,14 +46,16 @@ struct cmd_results *cmd_bar(int argc, char **argv) {
 		return error;
 	}
 
-	if (find_handler(argv[0], bar_config_handlers,
-				sizeof(bar_config_handlers))) {
-		if (config->reading) {
-			return config_subcommand(argv, argc, bar_config_handlers,
-					sizeof(bar_config_handlers));
+
+
+	if (!config->reading) {
+		if (!find_handler(argv[0], bar_config_handlers,
+					sizeof(bar_config_handlers))) {
+			return cmd_results_new(CMD_FAILURE, "bar",
+					"Can only be used in config file.");
 		}
-		return cmd_results_new(CMD_FAILURE, "bar",
-				"Can only be used in config file.");
+		return config_subcommand(argv, argc, bar_config_handlers,
+				sizeof(bar_config_handlers));
 	}
 
 	if (argc > 1) {

@ddevault
Copy link
Contributor

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?

@ianyfan
Copy link
Contributor Author

ianyfan commented Oct 13, 2018

I'm a bit confused what you're asking. The patch in the comment is just so you can run bar mode .../bar hidden_state ... at runtime.

As for this PR, it allows using the bar subcommands mode, hidden_state and modifier as expected, in the config file and during runtime.

Example:

bar {
    mode hide
    hidden_state hide # default, but provided here for explicitness
    modifier Mod4 # also default
}

hides the bar, but shows it if you press down Mod4 or when there is an urgent workspace.

bar mode invisible hides the bar completely.

bar hidden_state show which only has an effect in bar mode hide behaves like hide but the bar is always shown, on top of the 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.
@ddevault
Copy link
Contributor

I'm dumb, I was running /usr/bin/swaybar instead of ./swaybar/swaybar

@ddevault
Copy link
Contributor

LGTM, why [WIP]?

@ianyfan ianyfan changed the title [WIP] Bar mode/hidden_state events Bar mode/hidden_state events Oct 14, 2018
@ianyfan
Copy link
Contributor Author

ianyfan commented Oct 14, 2018

Forgot to change it

@ddevault
Copy link
Contributor

Thanks!

@ddevault ddevault merged commit 4a05fbf into swaywm:master Oct 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants