Spin-off from bug 153580: in order to manipulate more than three sort criteria it would be desirable being able to resize the dialog. The dialog size should be remembered, at least during the session.
+1 This is a valid request. In cases like this, I believe the best option is to "remember" the dialog size for each document, thus saving the dialog size info inside the document itself. Would this be possible? I'm saying this because if I open a document that requires many filter criteria and that I previously had resized the sort dialog, I would like to see its size remembered only for that document. But if I create a new empty document, I would like to see the default dialog size instead of using a previously "remembered" dialog size.
If the above option (in comment #1) is not possible, than it might be better to just remember the size during the same session.
FWIW, the original problem/request from the user was that he wanted to be able to navigate through / by the sorting steps/conditions, either by means of the mouse wheel or by keyboard (e.g. PgUp/PgDn). So, independently of the size of the dialog, a user would be able to quickly move from one condition to the next, or to the first, or to... by keyboard or mouse wheel. This is not the issue in this RFE, but it was also not dealt with in the original report either.
(In reply to Rafael Lima from comment #2) > If the above option (in comment #1) is not possible, than it might be better > to just remember the size during the same session. Original reporter here... Saving the dialog size for each document sounds lovely, but I cringe to think what would happen when editing an Excel document, or editing the Libre document in my iOS Collabora app. I'd be happy with the resized height being stored within Libre, either as a permanent config or just for the session with the open document. And yes, perhaps the more important part of my original request was to make the scrolling section of the dialog respond to mouse wheel and navigation keys! With that enabled, the size problem is much less significant.
(In reply to Loren Amelang from comment #4) > Original reporter here... Saving the dialog size for each document sounds > lovely, but I cringe to think what would happen when editing an Excel > document, or editing the Libre document in my iOS Collabora app. > > I'd be happy with the resized height being stored within Libre, either as a > permanent config or just for the session with the open document. The important thing to save in the document is how many sort criteria there are for the range. Then let the browser decide on the dialog size based on this value and on the device's implementation of LO and/or potential user preference setting for resizing the dialog according to the number of sort criteria.
The resize flag is on the UI, storing the size not rocket science. Medium difficult because no sample code provided here (but easy to find).
Oleg: realized that you are assigned to this issue after implementing it myself. My solution is here https://gerrit.libreoffice.org/c/core/+/151042, feel free to submit yours and I'll abandon it.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/95ae136380906c6d270fd47b2b9655b2c32f670e Resolves tdf#153852 - Make sort dialog resizable It will be available in 7.6.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.
(In reply to Commit Notification from comment #8) > It will be available in 7.6.0. The dialog is resize-able now in 7.6.alpha, but there seems to be a problem. 1. Set some sort to several adjacent columns and accept/ok the dialog. 2. Reopen the sort dialog. The mouse wheel allows to scroll, _always_ starting from the bottom. 3. Change one item from ascending to descending and accept the change. 4. Reopen again the sorting dialog. The focus is on the first sort key column, but the dialog starts by the bottom. 5. Use the mouse wheel to scroll up. When the first key is displayed, move the mouse pointer to the first key column and turn the wheel downwards and upwards over it. The action changes the first key column, which eliminates the whole set of sorting keys. This is not new. But... The combination of points 2 and 5 will generate annoyed users, having to rebuild their sorting keys, just because the existence of the new vertical scroll while the dialog is always opened at the bottom of the sorting keys. I guess that Loren's feedback regarding usability (e.g. replicating the above procedure) could be crucial. Otherwise this new scroll bar will be counterproductive.
If you think the focus should be on the last but visible control please file a new ticket.
(In reply to Heiko Tietze from comment #10) > If you think the focus should be on the last but visible control please file > a new ticket. The new scrollbar should _not_ default to the bottom.
I didn't add a scrollbar. The dialog dynamically creates the entries 1..n and by creating you scroll down. But as said before, this resize issue is resolved/fixed.