Feature request: Cagebreak state over ipc socket

[kinleyd]

While fully recognizing - and appreciating - Cagebreak's keyboard orientation, would it be possible to accommodate support for screen change on mouse over? This would help avoid a series of key presses on multi-screen setups and improve overall ergonomics.

Thanks.

[project-repo]

As you correctly recognised, cagebreak is designed to be completely keyboard-oriented. However, I understand that for the multi-monitor setup you describe it may be useful to have some kind of mouse-compositor interaction. To accommodate this, we are considering implementing a command which allows to obtain the current cagebreak state from the ipc socket, including the current cursor position. That way, by implementing a script which listens for cursor events and acts accordingly, it should be possible to implement the behaviour you describe externally (provided #11 is implemented as intended). What do you think?

If you have any other ideas, don't hesitate to let us know!

cheers project-repo

[kinleyd]

It sounds most excellent!

[project-repo]

There has been much talk about #12 and how it would improve all sorts of use cases, once implemented. While much remains to be determined, we would like to give an update.

First, #12 is secondary in priority to #11, which is presumably easier to implement and much clearer in its scope.

Once implemented, cagebreak will communicate the state of at least the following internal properties:

• [ ] Current cursor position (allowing setting of the current screen as per #11
• [ ] IDs for graphical programs along with position on screen
• [ ] IDs for tiles on particular screens
• [ ] Currently focussed tile, screen, etc.
• [ ] Events such as "new window", "screen split", etc.

In which format this information will be provided is yet to be determined, but we are considering at least the following:

• full blob of data upon request via ipc socket
• partial information on events

To improve user experience, the release of #12 will include examples of how to use the new API over the socket for real world use cases, analogous to the current example config.

• [ ] Example script "Current screen follows cursor on click"
• [ ] Example script "Setup multi screen environment with graphical programs on specific tiles"

Note that this is just the current state of planning, the final properties of cagebreak are specified in the man pages upon release and cagebreak is provided as is, as specified in the LICENSE.

cheers project-repo

[kinleyd]

Thanks, that sounds awesome - greatly looking forward to the new features when they land!

[kinleyd]

Example script "Current screen follows cursor on click" Regarding the above, allow me to suggest "Current screen follows cursor" as a more ergonomic option - we get to avoid the click, and the mouse serves as a wand instead. EXWM affords this amenity and I wholeheartedly recommend it.

[project-repo]

Some but not all features mentioned in our previous comment have now been implemented on the development branch.

Information on current events is provided through the ipc socket now. The types of events which are reported are still subject to change and the feature is not yet documented but you may check it out nonetheless. Let us know if there is any additional information you would like to obtain for the different events.

Current format displayed on the socket is as follows:

cg-ipc<4 bytes denoting message length><keyword denoting the type of the event>(<property1>:<value1>,<property2>:<value2>,...,<propertyn>:<valuen>)

Consider it a proof of concept.

A full dump of the current cagebreak state is not yet possible.

Happy new year to you too! cheers project-repo

[kinleyd]

Yes, I see the information on the ipc socket. View, tile, workspace and output information are already included, which is great. So for me it looks like only mouse events haven't been covered yet.

Where/how would we set up our configuration to read these events and respond dynamically?

[project-repo]

We pushed some code to development implementing the dump functionality. This should contain the information you require since it gives you the view currently focussed by the pointer from which you can deduce the output the cursor is currently hovering over by looking up the output on which the view is placed. Note that this only works when the cursor is actually hovering over a view (i.e. not when it is on an empty tile). Alternatively, you could read the cursor coordinates and compare these with the coordinates of the different outputs, though atm the coordinates of the outputs are not dumped (we aim to add this later).

To anyone who reads this: This feature will remain on the development branch for some time, partially due to some unresolved xwayland and wlr_scene bugs and partially to allow breaking changes (removing/changing data outputted by dump and other information sent by IPC). So if anyone would like to see something changed, please feel free to let us know (either by posting here or opening a new issue)!

cheers project-repo

[kinleyd]

Hey, thanks guys. Looking forward to checking it out.

[kinleyd]

Hi,

Great to try out all the dev features!

As I said before, happy to see 'screen #', 'movetoscreen #', etc. already incorporated. Awesome! They fill out some necessary functionality.

I also took a look at Cagebreak state over IPC. I do see state changes automatically reported on the socket when I change screens. And when I make a dump call, I do see screen/output info (DP-1, 2 and x,y coordinates).

Where would I insert the code to parse this information so that 'screen n' is called automatically when the mouse moves to another screen, and could you give me some example code as well? Thanks.

[project-repo]

Thank you for your feedback.

Regarding your question of "inserting code" - this is not possible. The current concept is that information is provided over the socket - what the user does with it, is the users business. It should be possible to attach a program to listen to the socket and react to events in whichever language has facilities for interaction with IPC sockets.

Regarding the more specific request for automatic screen change on mouse hover change, we are currently reevaluating the addition of a specific event for this situation. This event would announce screen change of the cursor over the socket, reducing programming effort to implement what you want to do specifically. We will announce it here if or when this code is added.

Regarding example code - We are in the process of creating a library of shell examples (maybe with a dependency a network tool such as openbsd-netcat). We will let you know once something is ready to be checked out. Please let us know if you would like to see any particular network tool used or example implemented (except the mouse hover screen change thing, that is on hold until a proper event is implemented).

cheers, project-repo

[kinleyd]

Regarding your question of "inserting code" - this is not possible. The current concept is that information is provided over the socket - what the user does with it, is the users business. It should be possible to attach a program to listen to the socket and react to events in whichever language has facilities for interaction with IPC sockets.

Regarding the more specific request for automatic screen change on mouse hover change, we are currently reevaluating the addition of a specific event for this situation. This event would announce screen change of the cursor over the socket, reducing programming effort to implement what you want to do specifically. We will announce it here if or when this code is added.

That would be awesome.

Regarding example code - We are in the process of creating a library of shell examples (maybe with a dependency a network tool such as openbsd-netcat). We will let you know once something is ready to be checked out. Please let us know if you would like to see any particular network tool used or example implemented (except the mouse hover screen change thing, that is on hold until a proper event is implemented).

Great! An expanded collection of sample code would be most useful. I have settled on nmap-netcat as my preferred network tool - it would be terrific if you could use this for demonstrating examples.

Thanks very much!

[project-repo]

We took a look at this today and as it turns out not that much is actually needed to enable this feature. We've just pushed some code to the startup_failed branch which sends an event over IPC every time the cursor changes output. What do you think? We're working on the bash scripts, although they may take a bit longer.

Cheers project-repo

[kinleyd]

We took a look at this today and as it turns out not that much is actually needed to enable this feature. We've just pushed some code to the startup_failed branch which sends an event over IPC every time the cursor changes output. What do you think?

This sounds most excellent! Yes, I now see the event cursor_switch_output. Could I suggest also covering every time the cursor changes tile, which would be useful when an output is split into multiple tiles?

We're working on the bash scripts, although they may take a bit longer.

I look forward to that!

[project-repo]

Hi, we just pushed some code to the development branch which sends an ipc event every time the cursor changes tile (to compile it, you can simply change startup_failed to development in the PKGBUILD). What do you think?

Cheers project-repo

[kinleyd]

Well, what can I say. This is so quick, and awesome. Great job!

Now the only thing I want to say, and of course purely from my own use case and experience, is: please make it the default behaviour!

Here's my pitch: A pure keyboard only person would not notice anything as he/she would be expected not to be waving a mouse in the first place, and hence would not be surprised by a silent change in current output or tile. And a person who is happy using the mouse where it is useful, such as I, would be saved a lot of keystrokes. :)

[project-repo]

Great, glad you like it! I'm not quite sure what you mean with default behaviour though: Do you mean that the dump output contains the info about tile switches? In that case, this will become the default behaviour once the development branch is merged to master in the next release.

Cheers project-repo

[kinleyd]

Great, glad you like it! I'm not quite sure what you mean with default behaviour though: Do you mean that the dump output contains the info about tile switches? In that case, this will become the default behaviour once the development branch is merged to master in the next release.

No, what I mean is, upon mouse over of the output or tile, silently switch to that output or tile without any configuration required on the user's part.

[project-repo]

Oh, in that case, I don't think we will be making this a default behaviour. Cagebreak is designed to be completely pointer agnostic and it doesn't really fit into the overarching concept to support this. Moreover, it may sometimes happen that even users who wish to use only the keyboard will have to use the mouse sometimes e.g. to use firefox. In these cases, an automatic refocus would drastically change the user experience as you can f.e. no longer simply move the mouse to the corner of the screen when typing or click on a non-focussed tile. We do however plan to explain how this feature can be simulated using the functionality which has just been added.

Cheers project-repo

[kinleyd]

That sounds reasonable. Just trying to push my personal use case. ;)

[project-repo]

Hi kinleyd,

we have finally implemented this as specified in the man pages. Two example scripts are included with the release.

I am closing this issue.

cheers and thank you for your input project-repo

[kinleyd]

Awesome - thank you!

[kinleyd]

we have finally implemented this as specified in the man pages. Two example scripts are included with the release.

Hi, I can't seem to find the example scripts in the man pages. Could you point out the section to look for?

[project-repo]

Hi kinleyd

the directory is aptly named example_scripts.

cheers project-repo

[kinleyd]

the directory is aptly named example_scripts.

Ah, that is apt. Thank you! I was looking in the man pages.