Created attachment 121828 [details] screenshot this is an UI enhancement about the "Tools/Customize" panel as you may see from the attached screenshot sometimes the text can be long enough to go beyond field bounds you can use horizontal scrollbars but I think that it would be easier for the user to manually resize the whole panel like other UI panels already do (i.e. Tools/Autocorrect/Autocorrect Options) I put Caolan to CC list since I know he worked on this topic in the past. this issue is inherited from OOo and still reproducible in current 5.2.x master builds.
set to new
I disabled resizing on purpose. When an item’s label is longer than what its container allows to see, the right solution is a tooltip that appears immediately on hovering with the mouse pointer.
An example of the tooltip I’m talking about: http://i.stack.imgur.com/qGV3J.gif
hi Adolfo, I gently ask you to reconsider your decision. I'm aware of tooltips but they allow you to see the content of only 1 item at once and you have to precisely point your mouse over that item and wait for the item tooltip to appear. but when you have to rapidly inspect a lot of items (this happens me frequently when I want to check all the existing shortcuts to my macros... and those macro items are always out of bounds as you may see from the screenshot) this become time-consuming and frustrating. a simple horizontal and vertical resize to enlarge the panel would save me (and other users in my situation) a lot of time. I think that you did not consider this scenario when you disabled the resizing of the panel, so I gently ask to bring back the users this chance. I remember the same thing happened in the past with the autocorrect panel. Caolan made it resizable, you disabled it, but you reverted your change after considering there was a valid case to make it resizable, see Bug 67040. so please revert this one as well.
I think I’ll be working instead on creating a better layout for this dialog… The small boxes are silly anyway.
(In reply to Adolfo Jayme from comment #5) > I think I’ll be working instead on creating a better layout for this dialog… > The small boxes are silly anyway. True. the small boxes are silly and you find a way to get ridof the horizontal scrollbars it would be an improvement and would be welcomed. Anyway I still think that resize should be allowed again since a vertical UI enlargement would show much more of the keyboard shortcut list and would allow me (and other users) a more panoramic view of the current setup, just like in the autocorrect replacement list
(In reply to Adolfo Jayme from comment #5) > I think I’ll be working instead on creating a better layout for this dialog… > The small boxes are silly anyway. Don't forget to look at https://bugs.documentfoundation.org/show_bug.cgi?id=96705 and http://user-prompt.com/de/how-to-make-libreoffice-customization-usable/ when doing so :) thanks! Cor
(In reply to Cor Nouws from comment #7) > ... > > http://user-prompt.com/de/how-to-make-libreoffice-customization-usable/ > ... I cite Cor words from the webpage above: ........................................... Kommentar vom 23. Januar 2015 um 22:40 Hi – great improvement for customising menu and tool bars. But I miss the possibility to see all available key combinations and the functions they are assigned too as well as an option to customize events. Will that be offered with the current dialogs? ........................................... so the ability to see the whole list of key combination is a valid reason to have a resizable list. please Adolfo, don't take it personally, but I really don't see what was the rationale and the advantage to disable the resizability of that dialog. Caolan work was to make all UI dialogs resizable so why did you disabled some? IMHO it always better to have something you can decide to resize or not... 2 chances is always better than 1. so I gently ask to revert you committ and make the dialog resizable again, then any other improvement to the dialog itself would be appreciated as well. so please consider changing the current WONTFIX status
I ask to the ux-advise team to evalutate my enhancement request. as said in previous posts, disabling the resizability of that dialog had no beneficial effect and instead limited user experience in some situations, so I gently ask Adoldo to revert his change and restore the original behaviour of that dialog that was made resizable by Caolan McNamara
First, there is no need to spam UX-Advise. Second, you are making it sound like I have some conspiracy against resizable dialogs (or against Caolán), and it is not the case. It is just that resizability is an optional feature for *dialog* windows, and must be enabled on a per-case basis, instead of having it enabled everywhere. Contrary to what you think, there are dialogs that must not be resizable, such as error messages. Pick any application in your Windows box and look at the dialogs. This is not a weird idea of mine. I already told you I will fix the dialog, I am preparing a commit. IT is just that I had other things to do first, such as producing the icons for the new Save button.
I always used the words "gently ask" to give to suggestion to revert the change. I'm sorry you misunderstood it as an attack towards you. I never had such an intention and this a wrong interpretation of my posts.
I'd join the conspiracy :-). Nevertheless it's a valid use-case but modal dialogs have to be non-resizable. We talked about this issue on the ML (http://listarchives.libreoffice.org/global/design/msg07373.html) and the UX team with the conclusion that dialogs shouldn't be resizable because it's uncommon, anchoring of controls is complex and never satisfying, and the content should get improved rather than making resize necessary. The exclusion are dialogs that require user input. Still missing is to add this to the HIG and blog about the guideline, sorry. Sooner or later the customization dialog needs a complete revamp. At least when the extended toolbar will be realized with the maximum configurability as designed.
(In reply to Heiko Tietze from comment #12) > I'd join the conspiracy :-). Nevertheless it's a valid use-case but modal > dialogs have to be non-resizable. We talked about this issue on the ML > (http://listarchives.libreoffice.org/global/design/msg07373.html) and the UX > team with the conclusion that dialogs shouldn't be resizable because it's > uncommon, anchoring of controls is complex and never satisfying, and the > content should get improved rather than making resize necessary. sorry but I don't understand if you are in favor or against giving back resizability to that dialog. > The exclusion are dialogs that require user input. Still missing is to add this > to the HIG and blog about the guideline, sorry. just like the autocorrect replacement table was and it was enabled again. I think the customize shortcuts panel would benefit too from vertical and horizontal manual resize to have a panoramic view of all the existing shortcuts as explained before... there's user imput too there when you manual modify or enter new shortcuts > Sooner or later the customization dialog needs a complete revamp. At least > when the extended toolbar will be realized with the maximum configurability > as designed. a potential improvement would be to give different default sizes to the "category", "function" and "keys" boxes at the bottom which actually have the same size the "key" could be safely shrinked since even the longest key combination (i.e. Ctrl+Maiusc+F11) barely fills half of the space available and some of the saved space could be given to the "function" box which has the longest strings the
dialog still not resizable using 5.2.0.0.alpha0+ Build ID: 05618e74c77658da76f467a1ab328cb310a19e84 CPU Threads: 4; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2016-02-20_23:42:27 Locale: it-IT (it_IT)
(In reply to tommy27 from comment #14) > dialog still not resizable using 5.2.0.0.alpha0+ Hmm .. are you playing a fool here :) ? How many issues, actively followed and being discussed, have you fixed without notification in BugZilla? IMO commenting as you did above makes no sense.
I know Adolfo is preparing a patch (comment 5) so I just retested to see if there were news about it or not. other hackers work on the code and you never know if a committ from an other hacker has side effects on other issues even without direct notification. IMO there's no reason to start a flame, so please put some water on it... :-)
(In reply to tommy27 from comment #16) > IMO there's no reason to start a flame, so please put some water on it... :-) Ah... splash splash :) Thanks for your clarification and careful approach here. Cor
Adolfo Jayme Barrientos committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d8df531aba62c9695e267ce229ae2dd17b696774 tdf#96999 Allow resizing of Customize dialog It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
OK, the dialog is resizable now. I’m currently lacking time to do anything more complicated. However, I would like to stress on: 1) how much tooltips are needed for any long string appearing inside a box, 2) the layout in these cases is at fault because it’s ugly, inefficient and complicated to use (cf. Heiko’s comment 12), and 3) I hope that this year we are able to get a GSoC student to pick up the task on the revamp of the customization feature.
Adolfo Jayme Barrientos committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ba3f93dfc8956930969e8c8b45c4f22719d8003a&h=libreoffice-5-1 tdf#96999 Allow resizing of Customize dialog It will be available in 5.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
VERIFIED in LibO 5.2.0.0.alpha0+ Build ID: f64a190f52f9e9c76c2a0d18f072938b5df93aae CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-02-28_14:15:03 Locale: it-IT (it_IT) thanks Adolfo, I appreciated it.