I thought it would be useful to have a function to remember and restore the 
mouse pointer position when switching windows, so that continuity of operations
at the mouse pointer position can be maintained.

This may be difficult to implement, but please consider it.

"Takahashi, Naoki" <tkna91@gmail.com> writes:

Hi!

> I thought it would be useful to have a function to remember and
> restore the mouse pointer position when switching windows, so that
> continuity of operations at the mouse pointer position can be
> maintained.
>
> This may be difficult to implement, but please consider it.

Interesting idea.  Could you be a bit more specific about what you have
in mind?  Sway already has the mouse_warping option but that can just
make the mouse "warp" to the current container (in its middle) or to the
current output.

IIUC, when switching from window A to B, you suggest swayr should
remember the current mouse pointer position and save it as "mouse
location of A", and set the mouse to B's saved location.

Where should the mouse be pointed at when B has no saved location, yet?
To the top-left corner of the B window?  Or stick where it has been,
i.e., at the location saved for A?

Bye,
Tassilo

> Where should the mouse be pointed at when B has no saved location, yet?

If there is no saved location for B yet, or if the saved position is outside
the display range because of a change in display configuration, etc., it is
fine to ignore it (let sway do its thing).

If the mouse pointer position is restored when switching windows in tabs,
stacks or scratchpad on the same screen, the user may feel uncomfortable at
first, but will probably get used to the convenience.

There may be a way to specify the unit to manage the mouse pointer position in
config.toml from among per-display (output), per-container, and per-window, 
but for now, I think it is enough to manage only the mouse pointer for 
each window.

I have heard that in security-conscious specifications in Wayland, 
implementations such as saving and restoring the mouse pointer position can be 
difficult if the developer is not familiar with them.

I hope the following document will help smooth the development process.
Sorry if this is noise.

Pointer Position Detection:

    https://github.com/rvaiya/warpd/blob/master/src/platform/linux/wayland/screen.c#L75

Restore (move) pointer position:

    https://wayland.app/protocols/wlr-virtual-pointer-unstable-v1

Wayland's commentary book by Drew DeVault:

    https://wayland-book.com/

"Takahashi, Naoki" <tkna91@gmail.com> writes:

>> Where should the mouse be pointed at when B has no saved location,
>> yet?
>
> If there is no saved location for B yet, or if the saved position is
> outside the display range because of a change in display
> configuration, etc., it is fine to ignore it (let sway do its thing).

Hm, indeed.  When a window is moved from, e.g., one output to another, I
guess its saved location should be invalidated, right?

> I have heard that in security-conscious specifications in Wayland,
> implementations such as saving and restoring the mouse pointer
> position can be difficult if the developer is not familiar with them.

I surely won't use any low-level means but swaymsg commands such as
"seat - cursor set <x> <y>".

Bye,
Tassilo

> Hm, indeed.  When a window is moved from, e.g., one output to another, I
> guess its saved location should be invalidated, right?

If the pointer position can be saved as a relative position in the window 
(relative to the upper left corner?), I don't see a problem with leaving it 
enabled.
It may be troublesome at first to manage the pointer position relative to the 
window, but if that can be achieved, it would be administratively simple and 
easy to use.

In any case, I think it is a good idea to disable (ignore) the pointer 
operation when the pointer restored position is outside the window range, such 
as when the window is resized or the window is moved when the pointer position 
is recorded in the absolute position of the seat.

Also, it is best to ignore any window switching that is done by moving the 
pointer.

> I surely won't use any low-level means but swaymsg commands such as
> "seat - cursor set <x> <y>".

Certainly it would be best if sway and wlroots had those features.

"Takahashi, Naoki" <tkna91@gmail.com> writes:

>> Hm, indeed.  When a window is moved from, e.g., one output to
>> another, I guess its saved location should be invalidated, right?
>
> If the pointer position can be saved as a relative position in the
> window (relative to the upper left corner?), I don't see a problem
> with leaving it enabled.

Given that seat deals with absolute positions, I think that would be
quite cumbersome.  And I think it's totally common to have the mouse
cursor not on the focused window but somewhere else in which case a
relative position would be quite useless, at least when a window got
moved.

> Also, it is best to ignore any window switching that is done by moving
> the pointer.

That's not feasible for swayr.  I can only intercept events but that
don't tell why and how some node was moved.

>> I surely won't use any low-level means but swaymsg commands such as
>> "seat - cursor set <x> <y>".
>
> Certainly it would be best if sway and wlroots had those features.

Apparently, it seems to have the ability to move the pointer but no
means to query the current location...

Bye,
Tassilo

> Given that seat deals with absolute positions, I think that would be
> quite cumbersome.  And I think it's totally common to have the mouse
> cursor not on the focused window but somewhere else in which case a
> relative position would be quite useless, at least when a window got
> moved.

I understand, it certainly seems like a hassle. I think you are right, absolute
position is fine.
On top of that, just ignoring the pointer position if the restored pointer 
position is outside the window's range might be about right.

> That's not feasible for swayr.  I can only intercept events but that
> don't tell why and how some node was moved.

I understand. If only keystrokes trigger the recording and restoration of the 
pointer position, then I think it is fine as it is.


> Apparently, it seems to have the ability to move the pointer but no
> means to query the current location...

If you need a low-level area, I think the above references and the following 
issue would be helpful.

    - https://github.com/rvaiya/warpd/issues/142

I did a quick search and it seems that even with i3 there is no way to know the 
pointer position and that you should use a tool like the following

    - https://github.com/jordansissel/xdotool
    - https://github.com/TheWeirdDev/xpos

If that is the case, it still seems to be outside the scope of sway's 
implementation policy, so it would make sense to find or create an external tool.
I'll give it some more thought and if there doesn't seem to be an alternative, 
I'll make a suggestion to the developers I'm interacting with.

> Apparently, it seems to have the ability to move the pointer but no
> means to query the current location...

I don't know much about this, so sorry if I'm missing the point.
Is it possible to do this using the following wlroots functions, etc.?

    - /usr/lib/libwlroots.so
    - /usr/include/wlr/types/wlr_virtual_pointer_v1.h

"Takahashi, Naoki" <tkna91@gmail.com> writes:

>> That's not feasible for swayr.  I can only intercept events but that
>> don't tell why and how some node was moved.
>
> I understand. If only keystrokes trigger the recording and restoration
> of the pointer position, then I think it is fine as it is.

No, any focus change event would and there's no way to figure out the
cause of the event.  It might be a keystroke, a mouse action, a script,
a swaymsg call issued by swayr, ...

>> Apparently, it seems to have the ability to move the pointer but no
>> means to query the current location...
>
> If you need a low-level area, I think the above references and the
> following issue would be helpful.
>
>     - https://github.com/rvaiya/warpd/issues/142
>
> I did a quick search and it seems that even with i3 there is no way to
> know the pointer position and that you should use a tool like the
> following
>
>     - https://github.com/jordansissel/xdotool
>     - https://github.com/TheWeirdDev/xpos

Those are X11-specific and don't work with Wayland.  The former
references https://git.sr.ht/~geb/dotool but that also seems only to be
able to simulate mouse and keyboard input, not query the current mouse
pointer position.  Well, and moving the mouse can already be done with
just sway, so nothing to be gained here.

Bye,
Tassilo

"Takahashi, Naoki" <tkna91@gmail.com> writes:

>> Apparently, it seems to have the ability to move the pointer but no
>> means to query the current location...
>
> I don't know much about this, so sorry if I'm missing the point.  Is
> it possible to do this using the following wlroots functions, etc.?
>
>     - /usr/lib/libwlroots.so
>     - /usr/include/wlr/types/wlr_virtual_pointer_v1.h

I guess in theory I could.  There seem to be rust bindings to wayland
APIs available.  But I have absolutely no clue how to use them, or even,
if I/swayr are allowed to use them.  I.e., it's not unlikely that they
make sense/work only in the context and runtime of a compositor (such as
sway)...

So long story short: I don't intend to implement features in swayr which
require anything else than sway IPC (the menu program being a notable
exception, of course).

Bye,
Tassilo

> So long story short: I don't intend to implement features in swayr which
> require anything else than sway IPC (the menu program being a notable
> exception, of course).

For example, even if there were an external tool that just returned the 
absolute position of the mouse pointer on the sway when executed, 
wouldn't you want to use something that depends on something other than the 
sway?

"Takahashi, Naoki" <tkna91@gmail.com> writes:

>> So long story short: I don't intend to implement features in swayr
>> which require anything else than sway IPC (the menu program being a
>> notable exception, of course).
>
> For example, even if there were an external tool that just returned
> the absolute position of the mouse pointer on the sway when executed,
> wouldn't you want to use something that depends on something other
> than the sway?

I like it very much that swayr has no dependencies other than sway and
some menu program of the user's choice.  Having an optional feature
requiring some optional third-party tool would not be the end of the
world but complicate things for both users and me as the maintainer.

Bye,
Tassilo

> I like it very much that swayr has no dependencies other than sway and
> some menu program of the user's choice.  Having an optional feature
> requiring some optional third-party tool would not be the end of the
> world but complicate things for both users and me as the maintainer.

Indeed it is.
I guess I should hold off on this idea until 
we or someone comes up with an alternative.

Thanks for all your kindness.

"Takahashi, Naoki" <tkna91@gmail.com> writes:

> I guess I should hold off on this idea until we or someone comes up
> with an alternative.

You can try asking in the wider sway community if getting the pointer
location is somehow feasible using just the tools sway provides or even
file a feature request issue although, I think, sway's policy is still
"no new features which i3 doesn't have".

> Thanks for all your kindness.

You're welcome.

Bye,
Tassilo