kando-menu / kando

🥧 The Cross-Platform Pie Menu.
https://ko-fi.com/post/Kando-1-0-0-released-G2G5Z1DOS
Other
1.19k stars 26 forks source link

X actions #397

Open redhog opened 2 months ago

redhog commented 2 months ago

I'm thinking of using this together with https://github.com/redhog/InfiniteGlass For that., it'd be super useful to have three new menu item types:

The reason for this is that that's how all the components of my window manager communicates with each other. However, I imagine this would be useful far outside the context of this window manager too :)

Schneegans commented 2 months ago

Hi there! Thanks for the suggestion! For now, it is not possible to create backend-specific menu-item types. But this could be possible in the future!

Would it be possible to achieve what you want with some command line tool? Then you could simply use the "Launch Application" menu item (which just executes a shell command).

That being said, could you give some more information what each of these types would need as properties? I am not too familiar with the X11 protocol :sweat_smile: Would you like to send the messages to the topmost window? Or would you like to give the window ID in the menu editor? I guess we could use xdotool under the hood and support everything xdotool search supports? What kinds of X11 messages are there? How can we define them in the menu editor?

I would be super happy if you could describe this in much more detail as I am really no expert there :smile:

redhog commented 2 months ago

I guess a command line tool like xdotool works, it's just a tiny bit clumsy, at least if you don't wrap its syntax into nice json in the config :P

There are basically two, possibly three windows you might want to interact with: The root window, and the currently active (for input) user window, and possibly the one the mouse pointer is over

About X properties:

An X property has a string name (typically all upercase, like WM_NAME), is attached to a particular window, and has a value. The value has a type and a byte content (the actual value). The type is a string name, and there are many pre-defined ones, like INTEGER, STRING, ATOM etc.

To be precise, the names and types are interned strings, so called ATOM:s, so the server doesn't need to send around the full string all the time, just an ID for it. The value can also consist of one or more ATOM (interned string), meaning that each only takes up 32bits.

An application can subscribe to be notified when a property changes on a window.

About X messages:

An XClientMessage is sent to a particular window, and applications can subscribe to receive them. The content of a message is slightly limited, it has a message_type that is an (interned) string just like for properties, and a value that is maximum 20 bytes long. Note the point about ATOMs in the value and space requirement :)