Skip to content
This repository has been archived by the owner on Nov 1, 2021. It is now read-only.

Protocol for requesting keyboard modifiers #30

Open
harishkrupo opened this issue Nov 7, 2018 · 24 comments
Open

Protocol for requesting keyboard modifiers #30

harishkrupo opened this issue Nov 7, 2018 · 24 comments

Comments

@harishkrupo
Copy link

The idea is to use the change in modifiers information to be notified about the change in keyboard layout.
This is useful for applications like status bar to show the current keyboard layout. Please see swaywm/wlroots#1360 for more information.

@emersion
Copy link
Member

emersion commented Nov 7, 2018

I wonder if we could build a more general protocol. Can this be useful for other use-cases too?

Also, do we want to only provide modifiers, or do we want to provide more info?

@harishkrupo
Copy link
Author

I wonder if we could build a more general protocol. Can this be useful for other use-cases too?

There could be other use cases but I am unable to think of any.

Also, do we want to only provide modifiers, or do we want to provide more info?

More info as in, other events or more info along with the modifiers?
As for other events, sending key events could be dangerous. Maybe KeyEnter/KeyLeave along with the client to which it was sent? This could be useful for another applet which shows the application which has the current focus. But I guess we could get this information from swaymsg -t get_tree.
As for more info, we don't need more info for this use case but may be needed for other usecases?

@harishkrupo
Copy link
Author

harishkrupo commented Nov 9, 2018

Would something like this work? harishkrupo@0966640
Sorry if it is not proper, I have never written a wayland protocol before.

@ddevault
Copy link
Contributor

ddevault commented Nov 9, 2018

I don't actually understand what's supposed to happen after the client calls get_keyboard_modifiers with need_events = 1.

@emersion
Copy link
Member

emersion commented Nov 9, 2018

@harishkrupo Wayland protocols aren't RPC, they're asynchronous. You don't "call" methods, you send requests. Requests don't "return" values, instead the compositor can send events to clients.

@emersion
Copy link
Member

emersion commented Nov 9, 2018

I wonder if it's worth it to have such a specific protocol.

@ammen99
Copy link
Member

ammen99 commented Nov 9, 2018

@emersion This seems a nice addition to have (IMHO). But I'm not sure, can't the app somehow get this from the wl_keyboard?

@emersion
Copy link
Member

emersion commented Nov 9, 2018

This seems a nice addition to have (IMHO). But I'm not sure, can't the app somehow get this from the wl_keyboard?

If it's focused, yes. It doesn't work if it's a statusbar though.

@harishkrupo
Copy link
Author

@emersion @SirCmpwn @ammen99
The request is asynchronous. When the client declares that it wants the events by setting need_events=1, the compositor can add that to the list of clients that want the modifiers and send the modifiers to them along with the focused client.
In my wlroots RFC here swaywm/wlroots#1360, I had added this request to wlr layer shell and when the client calls this it gets registerd for the modifier events, the events are sent in wlr_send_keyboard_modifiers Here: swaywm/wlroots@cb53d4d#diff-b012ce40ba3e8e49502f88dcfe15cc2cR219

@emersion
Copy link
Member

I'd rather not change wl_keyboard semantics. Instead, it would be better to add a new interface with a modifiers event.

@harishkrupo
Copy link
Author

I'd rather not change wl_keyboard semantics. Instead, it would be better to add a new interface with a modifiers event.

Sorry, I didn't understand. Could you please explain?

@ammen99
Copy link
Member

ammen99 commented Nov 10, 2018

Sorry, I didn't understand. Could you please explain?

@harishkrupo What you do is reusing the wl_keyboard modifier event. It would be better if you just add an event modifiers in the new protocol you're writing, so that you don't use wl_keyboard in a way it is not intended to.

@harishkrupo
Copy link
Author

@ammen99 Thanks. got it :)

@harishkrupo
Copy link
Author

okay, updated it. harishkrupo@a868f4e

@emersion
Copy link
Member

This doesn't work when there are multiple seats (ie. multiple wl_keyboard).

Instead we'd need a request to create a wl_keyboard wrapper (a new object), which has a modifiers event.

Note: I'm still not sure this protocol is a good idea.

@harishkrupo
Copy link
Author

This doesn't work when there are multiple seats (ie. multiple wl_keyboard).

Instead we'd need a request to create a wl_keyboard wrapper (a new object), which has a modifiers event.

Makes sense.

Note: I'm still not sure this protocol is a good idea.

Any other alternative way to get layout details?

@emersion
Copy link
Member

Any other alternative way to get layout details?

Another alternative would be to have the sway IPC do this. It's probably not a better solution considering that it's sway-specific.

Has someone else thoughts about that?

@harishkrupo
Copy link
Author

@emersion I have updated based on your comments
harishkrupo@e6d8577

@emersion
Copy link
Member

The structure of the protocol looks good. Only missing thing is a destroy request in the first interface.

@harishkrupo
Copy link
Author

Okay, will add that.
BTW, why don't we have a destructor here: https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml#L28 ?
I actually copied this and edited it :)

@harishkrupo
Copy link
Author

@emersion I have added the destructor request. harishkrupo@d9c82c1
If it is good shall I open a PR?

@emersion
Copy link
Member

If it is good shall I open a PR?

Sure.

@ddevault Thoughts?

@harishkrupo
Copy link
Author

harishkrupo commented Nov 18, 2018

opened PR #31

@emersion
Copy link
Member

emersion commented Nov 1, 2021

wlr-protocols has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/30

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

No branches or pull requests

4 participants