:-)
Note: same key combinations as one uses in Calc / Writer to change column wdths
Whiteboard: proposedEasyHack -> ProposedEasyHack
In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval. Thank you and apologies for the noise
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]
is there still something open?
wondering what modern office users (not those from 2013 :p ) think of this idea..
-1 (removing hard-coded shortcut for split window /resizing)
(In reply to Heiko Tietze from comment #7) > (removing hard-coded shortcut for split window /resizing) I do not understand that, Heiko, sorry.
These alt+arrow shortcuts are clumsy and hard-coded. I prefer a clean implementation where users can un/assign shortcuts. My -1 was also inspired by bug 146906 / https://gerrit.libreoffice.org/c/core/+/173122 (pending acceptance from dev/a11y ML).
We discussed the topic in the design meeting. The only place where a splitter is changed per keyboard is Calc for the Split Window with shift+ctrl+f6. Alt+left/right (and top/down) changes the cell width/height (if the focus is not at the sidebar). Me struggles to understand why users need to adjust the UI per keyboard (if the sidebar width is inappropriate we need to improve the implementation). Default shortcuts, in particular when hard-coded, should be implemented only if absolutely necessary. => WF Although the request has no obvious use case it makes sense to add accessibility to the discussion. As a more general remark: key sequence interaction a la emacs/vim etc. would be nice, maybe realized per extension.
(In reply to Heiko Tietze from comment #10) > Me struggles to understand why users need to adjust the UI per keyboard Some users may be unable to operate a mouse due to a physical disability. Others (in particular power users) might just prefer using the keyboard. Making all functionality (also) available via keyboard is one of the essential a11y guidelines/principles, e.g. specified in WCAG: https://www.w3.org/TR/WCAG22/#keyboard-accessible > (if the sidebar width is inappropriate we need to improve the implementation). As a general thought: If there's *generally* no use case to adjust the size of some UI element (i.e. neither with the mouse, nor with the keyboard), that's another story and in such cases, the feature of being able to adjust the width/height/... can possibly be completely removed (independent of whether it's done using the mouse or the keyboard). I'm not sure whether that's a good idea for the sidebar though. What comes to mind is e.g. former WollMux (now "lots", https://github.com/LibreOffice/lots ) which among others allows to fill in (sometimes very complex) forms in the sidebar. Being able to adjust the size is quite useful then, depending on whether you're currently focusing on filling in the form or seeing the document.
(In reply to Michael Weghorn from comment #11) > Some users may be unable to operate a mouse... Sure, but the sidebar... > As a general thought: If there's *generally* no use case to adjust the size > of some UI element (i.e. neither with the mouse, nor with the keyboard)... So WF > Being able to adjust the size is quite useful then <Wollmux>... Very edgy case, 3rd party stuff, questionable solution
(In reply to Heiko Tietze from comment #12) > (In reply to Michael Weghorn from comment #11) > > As a general thought: If there's *generally* no use case to adjust the size > > of some UI element (i.e. neither with the mouse, nor with the keyboard)... > So WF Full quote was "As a general thought: If there's *generally* no use case to adjust the size of some UI element " ;´) IMO adjusting width of panes is definitely an existing use.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Cor Nouws from comment #13) > IMO adjusting width of panes is definitely an existing use. Assuming all issues are fixed this means you suggest to assign a precious shortcut for expanding the Gallery in order to show three columns instead of two. I disagree with this use case.