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.
Hi Caolán, is https://gerrit.libreoffice.org/#/c/72601/ meant to fix this issue ?
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.
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.
Hi tommy27, Could you please confirm this is still reproducible in master ?
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
Created attachment 151683 [details] what I see under gen in master
Created attachment 151684 [details] and under gtk2
(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..
aha, now I see it. https://gerrit.libreoffice.org/#/c/72989/ to address that
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.
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.
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
(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
(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
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.