full mouse control - Githubissues

I've been continuously using keyd and warpd for a couple of weeks now, and, as I wrote earlier, they have finally solved (almost) all of my input related issues. Before flooding you with warpd feature suggestions, I would like to start an open discussion about whether to add full mouse control to keyd (including drag/hint/grid mode) by merging the warpd code. Currently, I think that this would make sense, not only featurewise (there are a couple of things which are apparently not achievable with keyd/warpd running as separate tools), but also from a code standpoint. Let me state some pros and cons:

pros:

all input can be managed in one place
one could implement a "mouse layer" (control the mouse while a modifier key is held down, which is somewhat more efficient than activating/deactivating warpd). Of course one could implement this functionality separately in warpd, but then a modifier key is sacrificed exclusively for mouse use, while in keyd one could bind all the numerous unused keys on that layer to something useful.
full mouse control is present in QMK (according to your readme, this should have some weight...), and also in its big brother uhk (www.uhk.io). I own a UHK and also some QMK-keyboards, and use mouse control quite extensively on both.
one could think about mouse movement support in macros, although this would probably be overkill (at least I personally don't see any common use case). Maybe it could be useful when playing games, for example online chess. There are just a few cursor motions which don't change, so one could implement something like "click, go two squares up and click again" to move a pawn etc.
mouse control could become application agnostic (through the keyd application mapping script, although again this sounds somewhat exotic)
there is already some overlap in functionality, as both programs can click. However, the clicking of keyd is smarter as it properly maps press and release, while a warpd click presses/releases instantly. At least in my use cases press/release mapping is crucial, for example when dragging or resizing floating windows.
a combined program would use less system resources than both separately (although this is probably not a valid argument, as resource usage is already minimal)

cons:

purists might argue that a merge would contradict the unix philosophy but I think that this is somewhat subjective here. Partial mouse control is already present in keyd and it already presents a virtual pointer to the system, so why not control it completely?
time and effort needed (which is always scarce)

Here is the link to the QMK mouse support (which you surely already are aware of), it would be absolutely amazing to have this functionality in keyd as well, in particular the kinetic move mode: https://github.com/qmk/qmk_firmware/blob/master/docs/feature_mouse_keys.md

Also, let me add that in case you decide to do the merge and this becomes a long term project, I would be willing to help you in any way I can. I know how to program but don't know C, so this would be a good opportunity to finally get to grips with it. And of course I could do documentation/man page writing.

Thanks for the comprehensive feedback :). I've already toyed with this idea, but ultimately rejected it for a few reasons. The main one being that the two are really distinct projects which have slightly different design and usage goals that I would prefer not to conflate. \<insert hackneyed refrain about the unix philosophy here>.

pros:

all input can be managed in one place

Ah, but what kind of input? keyd is for keys, warpd is for warping (mice). I daresay the names alone should settle it for any right thinking input aficionado :P.

one could implement a "mouse layer" (control the mouse while a modifier key is held down, which is somewhat more efficient than activating/deactivating warpd).

This is an intentional omission (of warpd). I would contest that this actually more efficient in most cases, but I'm open to changing my mind if you can make a case for it (in a warpd issue).

Of course one could implement this functionality separately in warpd, but then a modifier key is sacrificed exclusively for mouse use, while in keyd one could bind all the numerous unused keys on that layer to something useful.

This isn't necessarily true, since one could just map the modified sequences in keyd to match the sequences expected by warpd.

full mouse control is present in QMK (according to your readme, this should have some weight...), and also in its big brother uhk (www.uhk.io). I own a UHK and also some QMK-keyboards, and use mouse control quite extensively on both.

I am not opposed to adding QMK style mouse functionality to keyd, but it naturally wouldn't be as flexible as warpd. The advantage of warpd is that it can display visual hints since it has knowledge of the display server, while keyd is intentionally display server agnostic.

one could think about mouse movement support in macros, although this would probably be overkill (at least I personally don't see any common use case). Maybe it could be useful when playing games, for example online chess. There are just a few cursor motions which don't change, so one could implement something like "click, go two squares up and click again" to move a pawn etc.

This is an interesting idea. If mouse movement was added to keyd it would probably be logical to extend the macro syntax to allow for variable movement in a given direction.

there is already some overlap in functionality, as both programs can click. However, the clicking of keyd is smarter as it properly maps press and release, while a warpd click presses/releases instantly. At least in my use cases press/release mapping is crucial, for example when dragging or resizing floating windows.

warpd has a drag operator for this purpose (v). You can use it toggle the state of the left mouse button for drag operations, and even pair it with hint and grid mode.

a combined program would use less system resources than both separately (although this is probably not a valid argument, as resource usage is already minimal)

The improvement would be negligible (keyd is already quite optimized, warpd less so). It would also add a lot of bloat for people who don't want a full blown visual cursor replacement (the X libraries are quite large).

cons:

purists might argue that a merge would contradict the unix philosophy but I think that this is somewhat subjective here.

Indeed! :P. Good thing there aren't any purists around. sweats profusely

Partial mouse control is already present in keyd and it already presents a virtual pointer to the system, so why not control it completely?

The limited (presently broken) mouse functionality currently in keyd just extends the notion of a key to a mouse button. As I've noted, I'm not necessarily opposed to adding limited mouse functionality a-la QMK to keyd, but it isn't a priority at the moment. Adding something akin to warpd (which also has a mac port) would be beyond the scope of the project and would entail pulling in a bunch of display server specific libraries, which would violate one of the design goals.

time and effort needed (which is always scarce) Here is the link to the QMK mouse support (which you surely already are aware of), it would be absolutely amazing to have this functionality in keyd as well, in particular the kinetic move mode:

https://github.com/qmk/qmk_firmware/blob/master/docs/feature_mouse_keys.md

Thanks for the link. I am peripherally aware of QMK's mouse support, but only briefly toyed with it (in a nascent state) some time ago. I intend to add some kind of pointer acceleration to warpd anyway.

I would be willing to help you in any way I can.

I appreciate the offer, but I currently have no intention to merge the projects.

The advantage of warpd is that it can display visual hints since it has knowledge of the display server, while keyd is intentionally display server agnostic.

This would be the main reason for me to be also not very happy about seeing warpd and keyd merged. However, limited QMK-style functionality sounds pleasant enough (though to be clear, I don't personally have a nagging desire for mouse control at the moment).

Just throwing an idea out there to potentially mitigate the limitations - keyd could write its mouse status to a UNIX socket so that an external script could read it and produce visual feedback in any way it wants? This approach could also be used for other kinds of feedback, like the layout indicator of #147.

(It does occur to me now that there is probably no way to figure out the current pointer position without being able to talk to the display server, so maybe this wouldn't work)

@rvaiya: First of all, thanks a lot for taking the time to patiently answer all my requests in such a timely, detailed and polite way. One reason more for becoming a keyd/warpd fan.

Actually, after your arguments, I now completely agree with you that a merge is in fact a very bad idea (it also showed that I did not think things through properly).

The advantage of warpd is that it can display visual hints since it has knowledge of the display server, while keyd is intentionally display server agnostic.

I completely agree with @slakkenhuis that this is the killer argument against a merge.

I have "added" mouse control to keyd by activating pointer control in X and mapping the keypad keys via keyd. Finer navigation is still done via hint mode in warpd (or a trackpoint if available), but quick movement can now happen layer wise. Whether this is temporary or permanent for me will become clear in the next days, after some testing. Of course it would be a cleaner solution to support pointer movement directly in keyd at some point in the future.

Regarding the other things, I'm opening separate threads for clarity and ease of tracking.

Thanks again and have a nice Sunday!

keyd could write its mouse status to a UNIX socket so that an external script could read it and produce visual feedback in any way it wants?

I also considered doing something like this, but the feature set of warpd is sufficiently unique that the resultant wire protocol wouldn't be generically useful and would just end up splitting the complexity across two code bases.

rvaiya / keyd

full mouse control #158