[Libreoffice-ux-advise] [Bug 117166] Improve UX of moving complex drawings with arrow keys

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=117166

--- Comment #4 from Eyal Rozenberg <eyalroz at technion.ac.il> ---
(In reply to Buovjaga from comment #3)
> So in essence, you would favour a solution, where only the selection handles
> are seen moving and no processing power is wasted on rendering the drawing
> itself?
> 
> I guess another (more complex to implement) way would be to replace the
> drawing with a low-quality proxy rendering on the fly.
> 
>
> Let's consult design team.

If we're getting into it, I'd differentiate at least three cases:

1. Movement key combination held down (that's a hardware abstraction layer
thing - not something LO should detect; I think)
2. Second move key (or another key combination?) pressed very closely after
first movement key (or another combination?)
3. Nothing pressed very closely after first movement (or other key combination)

The differentiation between the second and third case isn't clear, but it could
perhaps be based on whether the effect of the keypress can be comfortably
rendered before the next key/key combination registers.

So, for case 1 I would indeed like something like the effect of the moving
selection rectangle rather than the selection itself. A simplified rendering
(e.g. less lines/no area/no transparency/etc. could work too, but like you said
- implementing that is a big deal. Now, I do mean animation - along a
continuous path, not at intervals (Not 100% sure about this though).

For case 2 - Act similarly to case 1, but don't make it an animation; or
rather, a "stop-motion" animation - only render at the positions the move keys
would have placed the object.

For case 3 - Just render the whole thing like LO does now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.