[Libreoffice-ux-advise] [Bug 40917] UI: scrolling only by full row height

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Sat Oct 30 17:42:40 UTC 2021


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

V Stuart Foote <vstuart.foote at utsa.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|https://bugs.documentfounda |
                   |tion.org/show_bug.cgi?id=35 |
                   |759                         |
                 OS|Linux (All)                 |All
           Priority|medium                      |high
            Version|3.3.3 release               |Inherited From OOo
           Severity|normal                      |enhancement
                 CC|                            |erack at redhat.com,
                   |                            |kohei at libreoffice.org,
                   |                            |libreoffice-ux-advise at lists
                   |                            |.freedesktop.org,
                   |                            |vstuart.foote at utsa.edu
           Keywords|                            |needsUXEval

--- Comment #14 from V Stuart Foote <vstuart.foote at utsa.edu> ---
>From 3.5.0 builds onward, the multi-line input for the Formula Input Bar
(ScInputBarGroup) provides direct editing of a an over height cell including
cursor and page movements (provided by the edit engine) IMHO resolving bug
34689.

So yes, the Calc sheet rendered to VCL canvas only scrolls by single sheet
rows. Note also that the provided scroll bar control (up, down, and thumb
slide) also move in full row increments.

IIUC more precise/incremental scrolling has been necessary because the entire
sheet is the extend of the scroll, millions of cells-thousands of columns and
rows.

Contrasted to Writer tables, which provide precise/incremental scrolling (and
smooth scrolling) Calc sheets are much more complex. Rendering them for more
precise scrolling seems desirable but likely non-performant if the entire sheet
is being manipulated. Meaning there would need to be a new view shell framework
to allow off screen caching of a view port onto the sheet--controlled by the
range of visible/working cells.  

Complex stuff, and requires major refactoring of Calc needing some UX
envisioning. But the refactoring (to support some semblance of view ports into
a sheet) may be too much for a GSOC project.

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


More information about the Libreoffice-ux-advise mailing list