[Libreoffice-bugs] [Bug 125348] autocorrect replacement table default width is increased by long autocorrect entries and you can't resize it

[bugzilla-daemon at bugs.documentfoundation.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |vstuart.foote at utsa.edu
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from V Stuart Foote <vstuart.foote at utsa.edu> ---
Confirmed on Windows 10 Per 64-bit en-US with
Version: 6.3.0.0.alpha1+
Build ID: 6d6277f23337c8eae9acabdf830e33fcc3ee9923
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

So, this looks to have been done in master toward 6.2.0 with
https://gerrit.libreoffice.org/#/c/64254/

Masked by issues of bug 125241 bcz the autocorrection table would never
complete loading.

So, gives a UX problem when constructing TreeViewList columns by setting a
fixed width on dialog launch that holds the widest data value--not otherwise
constrained users can make them *really* wide.

For example, renaming attachment 134684 (acor_it.dat) to acor_en-US.dat and
placing into $ORIGIN\..\share\autocorr I receive an over width Autocorrect ->
Autocorrect Options: Replacement tab.

On a 4K screen, the replacment table width showed a maximum of 338 characters
of a 625 character "target" string "ECOGRAFIA CAVIGLIA...", and about the same
count for its replacement--resulting frame takes up close to full width of
display. Ugly in that it far exceeds the LO app frame.

So, reviewing this extreme autocorrection table, other than the noted string,
Tommy has about 20 auto-corrections over 250 characters, and several hundred
over 180.

To be expected, removing these overlong corrections from the table and
reloading does reduce the dialog frame size, but it still gets a width set to
the longest remaining corrections--and is still a frame with width set by
widest entry.

So width set to widest data record is maybe not the best UX, at least for
auto-correction tables that tend to be abused as in the attachment. 

Interested to see how the ReplaceFixedWidths and setting the FixedWidths toggle
affects UX.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190521/f78b37f5/attachment.html>