xoop: a tool to make the X cursor loop around the screen - Programming On Unix
Users browsing this thread: 3 Guest(s)
|
|||
For the lols I recently have been working on this little project I call xoop (found here).
Basically all it does is allow for the cursor in X to appear at the other end of the X screen when it hits one side. Here I mean screen like X means screen, i.e. the total areal sum of all monitors. A current limitation with multi-monitors is that it only really works if the X screen is rectangular, but as long as it is (same sized monitors side-by-side, or just 1 monitor) then it works great. At least, it works great on my system - so I am very interested to hear "it doesn't work" if someone has issues. At first it feels a bit weird but after a while it has become second nature, which I've found very interesting. Let me know what you guys think! |
|||
|
|||
Pretty fun !
Why did you bother setting up a window, and even support EWMH on it ? Was it needed ? I have two monitors of different size, so it doesn't work "as expected". You should consider testing the cursor position against the monitor size/position rather than your window's edge. That would be more adaptive to the various multi-monitor setups you can find in the wild. |
|||
|
|||
Another idea:
Set up pointer barriers (as in https://uninformativ.de/git/xpointerbarrier/) and warp the mouse when it hits a barrier. See also Peter Hutterer’s blog post on barriers, which explains the events. |
|||
|
|||
Quote:Why did you bother setting up a window, and even support EWMH on it ? Was it needed ? I used a window so I could use enter-notify events. What else could I have done (beside the barriers)? TIL about pointer barriers - very cool! And makes way more sense for this purpose. I'll look into using these instead. Quote:You should consider testing the cursor position against the monitor size/position rather than your window's edge. That would be more adaptive to the various multi-monitor setups you can find in the wild. Do you mean in the calculation of where to teleport the pointer to? Yeah there are a few things I use for this calculation, and I'm not restricted by one window (i.e. I could easily put on per output; much easier than trying to calculate the geometry of one window around all monitors! This would obviously require calculating based on monitor positions). My concern with the irregular multimonitor setups is that it isn't always obvious whether the pointer should teleport, or where to. In a T-shaped 2 monitor setup, what happens when the mouse hits the bottom edge of the top monitor where there isn't another monitor to go to? The top? What if it was an H-shaped 3 monitor setup. Going left-to-right inside one of the H legs you might expect it to appear in the other leg - inconsistent with the T. Although there might be some way to nicely account for all configurations, things begin to get complicated. |
|||
|
|||
I gave the tool a try today, I find it really cool.
It turns the idea of a desktop environment upside down by changing your screen into a Pacman world, a flat torus. I didn't initially understand what the tool does from the readme though. |
|||
|
|||
Glad you liked it.
I liked the description using a flat torus, so I've added that in a little description to the top of the readme. And I've also uploaded a video to demonstrate it, as a one or two people on IRC said that it wasn't very clear what it did. |
|||
|
|||
Great! a option to now unmaintained taralli.
I have not had the pleasure yet to build xoop, but one issue I had with taralli and eventually stopped using it is when tweaking say a slider or knob in a DAW or Gimp and others, is whenever the pointer loops, the thing I tweak also resets to zero, so it does not continue a decrease or increase a value on the amount of looping I do, if you get my drift. Now I don't want to get ahead of my self and claim xoop behaves the same without testing it. Anyways thanks, I love these suckless tools above all. |
|||
|
|||
I've not heard of taralli, and searching online didn't yield anything. Might you have a link for it?
xoop basically teleports the pointer to the other side of the screen, but the pointer continues what it was doing before. For example, if you highlight text on a webpage with the pointer and bring the pointer to the bottom edge of the screen, the pointer jumps to the top and the highlighted block updates. Unless I'm misunderstanding the problem you describe, you likely wouldn't have a slide or knob going off the side of the screen, and so it wouldn't be interfered with. |
|||
|
|||
Hi mcol, thank you for the reply.
Yep you nailed it, taralli lost it's selection on teleport. Unsure about selecting text, I only remember the issue with applications category I mentioned...but yeah i'll find out soon enough. Here you go https://github.com/kmcallister/taralli |
|||
|
|||
Oh very interesting! Their approach to the event monitoring isn't ideal, but they have a good idea for how to deal with setups with multiple desktops that are arranged in a complicated non-rectangular shape. They just let the user define what to do! Lol. Maybe one day I will implement that.
|
|||
|
|||
Got finally around to package it, and on first glance it does what I kind of suspected, the teleportation inverts the selection rather then continue, at least on my system. For some operations it's actually nice, but on others not so.
Think Blender has this built in, thats why it works as intended, it's been a while. The only way I can trivialy speculate on this is something like : while on trigger event (left/right mouse button etc) and on first teleport, cross into a virtual greater geometry which somehow syncs with the real pointer location on release. Sorry I'm trying to torus my head around this early in the morning and I'm not that helpfull :D |
|||
|
|||
Oh I think i understand what you mean... it you were going round and round the torus (say, left to right, left to right) several times, you'd want to scroll to keep going further and further? That would be something. I do wonder how that could be implmented. Perhaps it would require the dial to operate based on raw pointer motion, rather than position relative to starting position.
|
|||
|
|||
Yup, that would be something. I understand this is easier said then done.
And probably out of scope, and I'm not that interested in hammering further on this with my greatly limited knowlege of X11 and xcb. I will however inquery and return when there is something usefull to post :) Thank you for xoop, the chat and your time so far. |
|||
|
|||
No problem at all!
|
|||