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

New keyboard interactivity options #105

Merged
merged 23 commits into from
Jan 17, 2021

Conversation

dkondor
Copy link
Contributor

@dkondor dkondor commented Jan 7, 2021

Support more settings for keyboard interactivity, according to the changes suggested to the protocol here: swaywm/wlr-protocols#100

By opening this pull request, I agree for my modifications to be licensed under whatever licenses are indicated at the start of the files I modified

New setting allows "normal" keyboard focus semantics for windows on any layer. Proposed for new version of the protocol.
Copy link
Owner

@wmww wmww left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few nits, but the idea looks good. I only reviewed the library, not the examples. Of course merging is blocked on the upstream PR getting merged, so no rush to fix these things.

*/
void gtk_layer_set_keyboard_interactivity (GtkWindow *window, gboolean interacitvity);
void gtk_layer_set_keyboard_interactivity (GtkWindow *window, GtkLayerShellKeyboardInteractivity interactivity);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the below function break backwards compatibility. We'll want to deprecate the old functions but keep them around.

Copy link

@emersion emersion Jan 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since true == 1 and false == 0, this breaks ABI but doesn't break API. Depending on the project policy, this may or may not be okay.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am trying to keep the ABI stable (various versions are shipped with various distros, and apps should ideally work with all of them). It might even be ABI-compatible (enum types seem to be implementation defined), but no reason to play with fire here. Renaming the new function gtk_layer_set_keyboard_interactivity_type (or something) and keeping the old one marked as deprecated is not a great burden.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I've added new functions that are called by these.

src/api.c Outdated Show resolved Hide resolved
src/api.c Outdated
g_warning ("Invalid value for keyboard interactivity setting!\n");
return;
}
if (version <= 3 && interactivity == GTK_LAYER_SHELL_KEYBOARD_ON_DEMAND)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be a little cleaner to make this check in layer-surface.c. I think getting the version from the zwlr_layer_surface_v1 (which you'll have access to in that file) instead of from the layer shell global would be slightly preferable.

Copy link

@emersion emersion Jan 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

zwlr_layer_surface_v1_get_version can be used for this purpose. EDIT: ah, you're already using a similar function, cool. Some people aren't aware that these exist.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved the check there. The problem is that self->layer_surface can be NULL when this is called, so in that case, we still have to use the global object as fallback (I think it is cleaner to have the warning here and not have to make this check when committing the surface later).

src/api.c Outdated Show resolved Hide resolved
src/layer-surface.c Outdated Show resolved Hide resolved
src/layer-surface.h Outdated Show resolved Hide resolved
default_keyboard_interactivity = GTK_LAYER_SHELL_KEYBOARD_NONE;
} else if (value[0] == '1' && value[1] == 0) {
default_keyboard_interactivity = GTK_LAYER_SHELL_KEYBOARD_EXCLUSIVE;
} else if (value[0] == '2' && value[1] == 0) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0/1 could be handled to retain old behavior, but I wonder if it makes sense to handle 2. Using enum names is clearer.

Copy link
Owner

@wmww wmww Jan 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handling numbers seems unnecisarry. Just handling names should be fine. (I still haven't reviewed the changes to the examples fully)

@dkondor dkondor force-pushed the new_keyboard_interactivity branch from aa1b9b9 to 9ebafd2 Compare January 9, 2021 04:35
@emersion
Copy link

@wmww Ack on merging the wlr-protocols PR?

@wmww
Copy link
Owner

wmww commented Jan 12, 2021

Now that the upstream PR has merged I'll give this a full review when I have time. These don't block my initial review, but they will need to be done before merging:

P.S. let me know if anything about writing tests could be documented better.

@dkondor
Copy link
Contributor Author

dkondor commented Jan 16, 2021

Now that the upstream PR has merged I'll give this a full review when I have time. These don't block my initial review, but they will need to be done before merging:

* Pull in the final version of the layer shell protocol

Done already :)

* Remove the new example (we don't need individual examples for every feature, adding interactivity support to the demo is enough)

I'm not sure what you mean; the new files are part of the demo, just separated for clarity (I can merge them with one of the other ones).

* Add integration tests (see [test-set-keyboard-interactivity.c](https://github.com/wmww/gtk-layer-shell/blob/master/test/integration-tests/test-set-keyboard-interactivity.c), [test-get-keyboard-interactivity.c](https://github.com/wmww/gtk-layer-shell/blob/master/test/integration-tests/test-get-keyboard-interactivity.c) for examples, and [test/README.md](https://github.com/wmww/gtk-layer-shell/blob/master/test/README.md) for full test documentation (though you shouldn't need to understand most of it))

I did a first try at this by adding the following two files:
test/integration-tests/test-get-keyboard-interactivity-types.c
test/integration-tests/test-set-keyboard-interactivity-types.c

To make this work, I had to update the mock server to advertise version 4 of the protocol. I'm wondering if there should be an extra test that gtk-layer-shell behaves as expected on a lower server version and if that's easily achievable with the current setup.

@dkondor
Copy link
Contributor Author

dkondor commented Jan 16, 2021

Also, I'm marking this ready for review since the protocol and wlroots PRs have merged and the main functionality is implemented.

@dkondor dkondor marked this pull request as ready for review January 16, 2021 14:16
gtk_layer_set_keyboard_interactivity_type(window, GTK_LAYER_SHELL_KEYBOARD_ON_DEMAND);
ASSERT_EQ(gtk_layer_get_keyboard_interactivity_type(window), version >= 4 ? GTK_LAYER_SHELL_KEYBOARD_ON_DEMAND : GTK_LAYER_SHELL_KEYBOARD_NONE, "%d");
gtk_widget_show_all(GTK_WIDGET(window));
ASSERT_EQ(gtk_layer_get_keyboard_interactivity_type(window), version >= 4 ? GTK_LAYER_SHELL_KEYBOARD_ON_DEMAND : GTK_LAYER_SHELL_KEYBOARD_NONE, "%d");
Copy link
Owner

@wmww wmww Jan 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this will always be run against the mock server, no need for the version checks. We can assume it's on the expected version.

EDIT: I did that

To answer your question, yes, ideally we'd have additional tests for different protocols versions but we're not set up to easily implement that right now, so don't bother. I'll add those tests if/when I set up a way to make the mock server use different versions of protocols.

@wmww
Copy link
Owner

wmww commented Jan 17, 2021

I'm not sure what you mean...

Either the thing I was talking about was removed or I was just confused. Either way it's fine now.

@wmww
Copy link
Owner

wmww commented Jan 17, 2021

All right as you can see I've added a bunch of changes, including notably changing the names from "keyboard_interactivity_type" to "keyboard_mode". That diverges from the protocol terminology, but I think it's a little clearer, much shorter and less likely to be confused with the deprecated functions. Much appreciated if you want to give the PR a review in it's current state. It seems ready to merge to me.

Rename keyboard interactivity enum
@dkondor
Copy link
Contributor Author

dkondor commented Jan 17, 2021

All seems good, I've only added a minor edit in one place where the documentation was inconsistent.

Otherwise, I've just tested a bit and seems to work well.

@wmww
Copy link
Owner

wmww commented Jan 17, 2021

Awesome! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants