In previous version of Mageia (5) (Linux), with Libo 4.4.7.2 (and before), it was possible to have ascending and descending in the same sort, something which I use frequently. After updating to the latest version of Mageia (6), which uses Libo 5.3.4.2, the option for ascending or descending is no longer available by field being sorted. However pre-existing sorts seem to respect the previous functionality. The problem is not hardware related, so should affect all hardware. I expect that it would affect all operating systems since it is coded as such in the menus, so I marked it as all. It definitely does affect Linux (Mageia)
This should be marked as major as it is a serious regression in functionality which (in my case) requires returning to an older version of Libreoffice. However your configuration refuses to let me mark it appropriately.
No reproducible on Windows (Menu/Data/Sort). Version: 5.3.4.1 (x64) Build ID: 1b1606c6e1203cdc3fd5ffbc16e74ecea300241a CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: es-ES (es_ES); Calc: CL Version: 6.0.0.0.alpha0+ Build ID: 83288332f7ced698610739419989c464256f1c4d CPU threads: 4; OS: Windows 6.19; UI render: default; Locale: es-ES (es_ES); Calc: CL
Further tests show that libo apparently expands multiline heading fields to one (possibly very long) line, which did not occur with libo 4.4.7.2. A resulting very long heading field can be long enough to occupy the maximum width in the sort selection window, meaning that the ascending/descending buttons are no longer displayed. The solution is to reserve a space to the right for the ascending/descending buttons. A multiline heading probably contains supplementary info ABOVE the main heading text, meaning that if such a heading becomes too long, it is better to omit text above, or to the left of a combined line. eg. ---- very long explanation for a description ---- could become ---- ...explanation for a description ---- (Note that when libo combines lines it puts a space in place of CR)
Please attach a sample file for test.
Created attachment 136658 [details] sample file showing bug This file shows the problem, as reported. One use case is any table where it is more convenient to put info to be continually displayed in a large heading field to minimize verticle screen space used. eg. where other headings are already multi-line.
Created attachment 136665 [details] Screenshot How do you expect that calc could know what word(s) in the cell should be the field's title? First selecting Ascending/Descending works find for me. Second I't possible to select the field to sort Asc/Des, the whole content of the cell is showed. You can add a comment to the title's cell having it always showed, or add a line before to add some text about the field.
(In reply to m.a.riosv from comment #6) > Created attachment 136665 [details] > Screenshot > > How do you expect that calc could know what word(s) in the cell should be > the field's title? See comment 3. Also note that if the long title is NOT a sort field, this is a moot point. > > First selecting Ascending/Descending works find for me. > Second I't possible to select the field to sort Asc/Des, the whole content > of the cell is showed. But it doesn't work in the sample file. The ascending/descending buttons are not displayed. What is needed is a simple maximum length for the sort field selection that always allows the display of the following ascending/descending buttons. That is a design bug that should be fixed. (At least I always fix such bugs in my own code.)
Ok, I have a wide screen so there is no problem for me, but I understand the point. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha1+ Build ID: fff7097f1ed8493de099d79aa0613ea6b309100a CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 2nd 2017
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still repro in Version: 6.2.0.0.alpha1+ (x64) Build ID: b439cfda24676c5272e3fe30c0a521975f948274 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2018-10-24_08:08:13 Locale: ru-RU (ru_RU); Calc: threaded
https://gerrit.libreoffice.org/#/c/62905/
Roman Kuznetsov committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/d3b505c388537cc9a923da74b85aeeab79f3803a%5E%21 tdf#112604 Set a maximum width for the Calc Sort dialog It will be available in 6.2.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.
my "fix" was absolutely wrong and it just doesn't work as I expected I should reopen this
Dear andréb, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The test file works for me now, by displaying the sort options in a popup with ascending/descending reserved in a column to the right. The popup displays all 4 lines of the test heading of a wide column, with the middle of long lines being replaced by ... character. To me that is a very satisfactory solution : not only are the sort order options displayed, but a considerable width is now displayed, making it easy to identify the column in question. Tested with libo 7.3.6.2 (The latest version on the current official release of my distro of Linux) Thanks for fixing the issue. Will close as resolved / worksforme.