Download it now!
Bug 125348 - autocorrect replacement table default width is increased by long autocorrect entries and you can't resize it
Summary: autocorrect replacement table default width is increased by long autocorrect ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.2.4.1 rc
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.3.0 target:6.2.5
Keywords: bibisectRequest, regression
Depends on:
Blocks: AutoCorrect-Complete
  Show dependency treegraph
 
Reported: 2019-05-18 05:49 UTC by tommy27
Modified: 2019-06-07 09:47 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of an extremely enlarged replacement table width (108.34 KB, image/jpeg)
2019-05-18 05:49 UTC, tommy27
Details
what I see under gen in master (362.99 KB, image/png)
2019-05-26 14:11 UTC, Caolán McNamara
Details
and under gtk2 (502.96 KB, image/png)
2019-05-26 14:11 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tommy27 2019-05-18 05:49:07 UTC
Created attachment 151493 [details]
screenshot of an extremely enlarged replacement table width

this is a regression I've noticed in latest LibO 6.2.5.0.0+ (x64) but I suspect it affect the whole 6.2.x branch.

apparently the default width of the autocorrect replacement table (Tools/Autocorrect/Autocorrect options...) is permanently increased by the presence of long autocorrect entries.

try to load the table with default entries and see it's width.
now enter and save a very long entry (you may use dummy text like qwertyuiopèasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnm) and the reload it.

you will see that the default width of the table is dramatically enlarged (see my screenshot as well) and you cannot shrink it...

resize only works for the table's height but not for width.

the table keeps it's regular width in LibO 6.1.x despite the lenght of the longest autocorrect entry.

please fix it.
Comment 1 Xisco Faulí 2019-05-20 14:48:07 UTC
Hi Caolán, is https://gerrit.libreoffice.org/#/c/72601/ meant to fix this issue ?
Comment 2 V Stuart Foote 2019-05-21 06:42:08 UTC
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 [details] (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.
Comment 3 V Stuart Foote 2019-05-22 16:17:17 UTC
On Windows 10 Pro 64-bit en-US (1803) 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

Alas, no change to the unbounded width of Tools -> AutoCorrect -> AutoCorrect Options "AutoCorrect" dialog, with a large replacment table (number of replacements and their length) dialog expands to close to edges of available display width, interesting on a 4K monitor.
Comment 4 Xisco Faulí 2019-05-23 12:16:37 UTC
Hi tommy27,
Could you please confirm this is still reproducible in master ?
Comment 5 tommy27 2019-05-25 11:16:39 UTC
still present in  6.3.0.0.alpha1+
Build ID: 4b893906984a4620fda7e1914f0d1ea3416ef42c
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: it-IT (it_IT); UI-Language: en-US
Calc: threaded
Comment 6 Caolán McNamara 2019-05-26 14:11:32 UTC
Created attachment 151683 [details]
what I see under gen in master
Comment 7 Caolán McNamara 2019-05-26 14:11:56 UTC
Created attachment 151684 [details]
and under gtk2
Comment 8 Telesto 2019-05-26 14:32:47 UTC
(In reply to Caolán McNamara from comment #7)
> Created attachment 151684 [details]
> and under gtk2

It appears to be depending on the replacement table which gets loaded first. 
I'm able to reproduce after small modification:

1. Set the Locale setting (Options -> Language settings -> Locale settings) to Italian 
2. Restart LibreOffice
3. Open the AutoCorrect options dialog -> Result as Tommy27 described. 

[BTW, they delay before the dialog appears is also slightly annoying. Ideally they dialog shouldn't wait until the replacement table is fully loaded.. IMHO

Noe, I used the replacement table of bug 109158 (attachment 134684 [details]) not sure if it matters..
Comment 9 Caolán McNamara 2019-05-26 15:44:12 UTC
aha, now I see it. https://gerrit.libreoffice.org/#/c/72989/ to address that
Comment 10 Commit Notification 2019-05-27 08:02:09 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/ddbdd2e6d751c0708d915e58d9a39a546c61916a%5E%21

Resolves: tdf#125348 some an initial fixed width for the treeview

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Caolán McNamara 2019-05-27 08:11:38 UTC
So the super wide dialog problem is fixed in master, and backport to 6-2 in gerrit now. There are other changes in master to make this faster and (arguably) prettier.
Comment 12 V Stuart Foote 2019-05-29 00:34:46 UTC
That's got it, verified on TB of master. Thanks Caolán!

Version: 6.3.0.0.alpha1+
Build ID: 37103a3f008c13dee21d55c8da9e6af807b1997c
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 13 Xisco Faulí 2019-05-29 08:18:52 UTC
(In reply to V Stuart Foote from comment #12)
> That's got it, verified on TB of master. Thanks Caolán!
> 
> Version: 6.3.0.0.alpha1+
> Build ID: 37103a3f008c13dee21d55c8da9e6af807b1997c
> CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
> Locale: en-US (en_US); UI-Language: en-US
> Calc: threaded

Setting to VERIFIED then
Comment 14 tommy27 2019-05-29 11:39:01 UTC
(In reply to Caolán McNamara from comment #11)
> So the super wide dialog problem is fixed in master, and backport to 6-2 in
> gerrit now. There are other changes in master to make this faster and
> (arguably) prettier.

yes, the replacement table width bug is gone in master, thanks.

however I see no improvement in the overall loading speed of the replacement table
in 6.3.0.0.alpha1+ (*) compared to 6.1.3.2, but the speed issue is to be discussed in Bug 109158



(*) Build ID: 67fd47e909aa88584420c3351ab17308aeb4e911
CPU threads: 8; OS: Windows 6.1; UI render: GL; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-05-28_04:09:58
Locale: it-IT (it_IT); UI-Language: en-US
Calc: threaded
Comment 15 Commit Notification 2019-06-07 09:47:24 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/d0c5664add278379e07cec673f28d6aec35b1f81%5E%21

Resolves: tdf#125348 some an initial fixed width for the treeview

It will be available in 6.2.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.