Feature request: Cagebreak state over ipc socket
kinleyd opened this issue · 25 comments
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.
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
It sounds most excellent!
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
Thanks, that sounds awesome - greatly looking forward to the new features when they land!
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.
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
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?
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
Hey, thanks guys. Looking forward to checking it out.
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.
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
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!
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
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!
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
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. :)
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
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.
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
That sounds reasonable. Just trying to push my personal use case. ;)
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
Awesome - thank you!
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?
Hi kinleyd
the directory is aptly named example_scripts.
cheers
project-repo
the directory is aptly named example_scripts.
Ah, that is apt. Thank you!
I was looking in the man pages.