On Sun, Nov 21, 2021 at 03:29:29PM +0100, Dominik Vogt wrote:
> Situation: At the moment, interactive move with the mouse feels
> awkward. Pushing windows past the page edge often fails because
> the pointer hits the edge and cannot move further. It's annoying
> and uncomfortable. The "pointer hits page border" this is a real
> show stopper.
Yeah, that all makes sense.
> 1. When an interactive move starts:
>
> - Replace the pointer with an invisible one.
> - Warp the pointer to the middle of the screen. There it can
> always be moved in all directions.
> - If the pointer gets too close to the page edges, warp it back
> to the middle of the screen.
> - At the end of the move, warp it back to the original
> position relative to the window.
> (- Maybe a fake cursor can be drawn at the original position so
> that the user does not get confused.)
So... if I understand this correctly, you would have something like this:
+----------------------------------------------------------+
| S |
| |
| |
| |
| |
| |
| |
| |
| |
| P |
| |
| |
| |
| +----------------+ |
| | | |
| | | |
| | | |
| | W | |
| | | |
| | | |
| +----------------+ |
| |
+----------------------------------------------------------+
If I'm moving window W interactively, pointer (P) is moved to the middle of
the screen, if I move it right, the window follows that -- but at the distance
of the window's top border and where the pointer is, presumably?
What if I want to have window W moved to the top-right of the screen (S)?
Wouldn't my pointer end up being at the top of the screen before the window
could reach it, and hence the pointer would be warped back to the middle of
screen S?
> 2. Remove timed paging during interactive move completely
> (EdgeMoveDelay style)
Yes please.
> 3. Instead, when you push the original pointer position off page
> the viewport automatically starts scrolling to keep that
> position (the fake pointer) visible.
>
> Think of the current viewport position being connected with the
> original one with a rubber band: If you change you mind and
> move the window back towards its original position, the viewport
> also moves back, relaxing the rubber band.
I think I can visualise this in my mind -- and I think it makes sense as
moving a window is a conscious choice in that a user's going to know where it
started, and so treating its moving like an elastic band could work.
> 4. When the move ends, the window is placed and the viewport snaps
> back to a full page. It may be a bit tricky to choose the
> proper page automatically. It's easy if the window has
> completely moved to another page, but what if it's stuck between
> two or even four pages?
This concept between pages and viewing many different parts of the overall
virtual desktop has always meant situations like this happen even now. I
don't have a good answer to this.
We also need to think about:
* How FvwmPager is going to react to this -- I think it will handle the
scrolling nature just fine, but there's still a chance it might get
confused.
* Edge-sensitivity to 'DesktopConfiguration per-monitor' and screen boundaries
where paging could occur.
> 5. Visual feedback (optional)
> - Add a new "activity" colour to window decorations. This
> colour may be used while a long running action affects a
> window (interactive move/resize etc.).
>
> - The "activity" colour could also be used when a window
> border hits the page edge during an interactive move. Say,
> if the window is already at the edge and you keep "pushing",
> that border uses the "activity" colour to indicate that
> something is happening.
I think this is definitely going to be required, yes.
Kindly,
Thomas
