This is a follow-up from bug 154145. Calc's Format > Align Text menu needs to be improved, because: - its functions can be used for other things than text, for example shapes; - it does not contain the default option for horizontal and vertical text alignment, which needs to be present to revert a change made from the menu (and be on par with the toolbar's de-activating of alignment options; - its labels are inconsistent: horizontal "centered" vs vertical "center". Proposed Changes: - "Format > Align Text" relabelled to "Alignment" because it doesn't just affect text. This matches the tab title in the Format Cells dialog. - "Format > Align Text > Center" (for vertical section) is relabelled to "Middle" so it matches the Format Cells dialog. - Addition of both automatic alignment UNO commands, uno:CommonAlignHorizontalDefault and uno:CommonAlignVerticalDefault. The other, more obscure alignment options can live exclusively in the Format Cells dialog, as currently. - Documentation updated accordingly. Some of these changes revert to an earlier state: - uno:CommonAlignHorizontalDefault used to be there in OOo 3.3, but was removed somewhere along the way. - "Align text" used to be "Alignment" in OOo 3.3, but was relabelled somewhere along the way. Tested with: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cae0daff1dd8bd60208892c792948c0cd2b0eeec CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #0) > alignment, which needs to be present to revert a change made from the menu > (and be on par with the toolbar's de-activating of alignment options; I'm not sure I understand the need for that point. If I select a range of cells, set a certain alignment by pressing some icon on the toolbar, and then click again on the same icon, the result is the "default" alignment. I could change to "center", then "left" (icon looks pressed), then click again on "left" (icon looks normal, not pressed) and the resulting alignment is "default". Do we really need specific menu entries and/or icons for "default" alignment (one for horizontal and one for vertical)? What's wrong with having them in the dialog only? I'm not against it. I'm just asking. Another possibility could be to have the menu entries work as the icons; select once and the attribute is set (and the menu entry (icon) would look "pressed"); select the "pressed" menu entry again and the "default" alignment would be set. The menu entries and the icons in the toolbar(s) would/should be in sync.
(In reply to Stéphane Guillou (stragu) from comment #0) > - its functions can be used for other things than text, for example shapes; Isn't it in the cell formatting dialog though? > - "Format > Align Text" relabelled to "Alignment" because it doesn't just > affect text. This matches the tab title in the Format Cells dialog. What else does it affect? In the other bug, you mentioned "numbers", but numbers are also text.
Default would be right for numbers and left for text (in LTR). The alignment is implemented as single choice with radio buttons and while I could imagine solutions with checkboxes (switching it off means Default) this might be not easy to understand in itself and not handy for multi-selection. The to-be-introduced UNO command is not limited for the main menu. Users may want it on the standard toolbar or somewhere else.
(In reply to ady from comment #1) > (In reply to Stéphane Guillou (stragu) from comment #0) > > alignment, which needs to be present to revert a change made from the menu > > (and be on par with the toolbar's de-activating of alignment options; > > I'm not sure I understand the need for that point. It's a design principle: "Provide access to all functions via the menu bar" https://wiki.documentfoundation.org/Design/Guidelines Obviously, this is not applied 100% to all functions, otherwise we would have overwhelmingly large menus. But we should absolutely make the default setting available in the menu. > Another possibility could be to have the menu entries work as the icons; > select once and the attribute is set (and the menu entry (icon) would look > "pressed"); select the "pressed" menu entry again and the "default" > alignment would be set. The menu entries and the icons in the toolbar(s) > would/should be in sync. That's true, but seeing Heiko's comment, I'd go with the extra option. (In reply to Eyal Rozenberg from comment #2) > (In reply to Stéphane Guillou (stragu) from comment #0) > > - its functions can be used for other things than text, for example shapes; > > Isn't it in the cell formatting dialog though? I'm talking about the menu, not the dialog. I guess it's a UNO command that has different effects depending of what is in the current selection. > > - "Format > Align Text" relabelled to "Alignment" because it doesn't just > > affect text. This matches the tab title in the Format Cells dialog. > > What else does it affect? In the other bug, you mentioned "numbers", but > numbers are also text. I affects the relative position of shapes, see above. (In reply to Heiko Tietze from comment #3) > The to-be-introduced UNO command is not limited for the main menu. Users may > want it on the standard toolbar or somewhere else. I'd let you decide on this one. Toolbar allows "turning it off" back to Default, so the current situation is not as bad as for the menu.
The alternative that needs to be discussed is the existing "clear DF" function.
We discussed the topic in the design meeting. The toolbar buttons work as expected and reverting a toggle state brings back the default alignment. The main menu, however, seems to be a toggle function too according the checked state but it's not possible to untoggle an option. We suggest to fix this issue rather than introducing a "Default", which would then be required on other options too.
Dear Stéphane Guillou (stragu), 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