Request for critical review of the Tools - Options - LibreOffice Writer - Compatibility dialog. In particular: * better sequencing of options? e.g., all "paragraph and table" spacing options together? all the 1.1 options together? * maybe separate heading is unnecessary for "Form menu" if there is only going to be one change like this. (see also bug 126375, comment 2) "Reorganize" is not a good word for the label. Better label might be "Form dropdown menu like Microsoft". * general review of option labels for possible improvements/corrections (e.g., bug 141676) * is the scroll box really needed? (i.e., general design/layout of dialog can probably be simplified) Background for request: bug 131235 wants some missing features added to help page (see bug 131235, comment 1). Would be good to make UI improvements before help page is updated.
Relevant help page: https://help.libreoffice.org/24.2/en-US/text/shared/optionen/01041000.html
Created attachment 189339 [details] Dialog (In reply to sdc.blanco from comment #0) > * better sequencing of options? > > e.g., all "paragraph and table" spacing options together? > all the 1.1 options together? Sounds good to me (and has no consequences for the l10n team) > * maybe separate heading is unnecessary for "Form menu" if there is only > going to be one change like this. (see also bug 126375, comment 2) This one is a global option while all other are saved per document. There are a few more yet not exposed at the UI, see https://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/Office/Compatibility.xcs?r=28675af8#168 > "Reorganize" is not a good word for the label. > Better label might be "Form dropdown menu like Microsoft". "Microsoft compatible Form menu" maybe. But I'd rather omit this option as a corner case and to clean up the dialog. > * general review of option labels for possible improvements/corrections > (e.g., bug 141676) As a rule of thumb we could start the entries with an action. Like "Add.." , "Use..." etc. "Word-compatible trailing blanks" could become "Use...". I don't like "Protect form (..." but ultimately all these options requires to study the help. And I'd keep the burden low for l10n. > * is the scroll box really needed? (i.e., general design/layout of dialog > can probably be simplified) Nothing bad with it on macOS.
Created attachment 189341 [details] screenshot of Windows dialog for Compatibility options (In reply to Heiko Tietze from comment #2) > (In reply to sdc.blanco from comment #0) > > * is the scroll box really needed? (i.e., general design/layout of dialog > > can probably be simplified) > > Nothing bad with it on macOS. Attachment has screenshot for Windows. Two differences with macOS 1. Some options (toward bottom) do not fit fully in horizontal direction in Windows. 2. Top 3 options are missing in Windows, but not macOS. OP was imagining something like macOS. A Windows problem? Linux? Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 218a7650a5cf03f895bed19c68d6f02daec536e9 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded
(In reply to Heiko Tietze from comment #2) > "Microsoft compatible Form menu" maybe. But I'd rather omit this option as a > corner case and to clean up the dialog. Does "clean up..." mean a different design/layout for the entire dialog? But doesn't the label deserve to be changed in either case (i.e., cleaned-up or not)? > I'd keep the burden low for l10n. Agreed. Also agree that studying help is usually needed (i.e., no expectation that each option is transparent, only sufficiently meaningful to remind about the function (if you already know the meaning) or to indicate enough about the likely function, to decide whether worth looking further at the help). Most options seems to have an action verb. Propose the following changes: A. "Consider wrapping styles when positioning objects" Two issues here. First, according to help [1], it seems like it would usually be preferred to have this option ON, but afaict, the default is that this option is OFF. Is the help wrong? or maybe the default should be changed? If I understand the idea here, then it seems better to change the label to "Use OpenOffice 1.1 wrapping style to position objects" (and to change the backend so that when it is ON, then the "old" behavior is used). (would make it more consistent with the other "Use OpenOffice.org 1.1..." B. Protect form.... Help is missing. (I do not know what what this function does, but given that it is not documented, then seems better to make a reasonable label, and then add appropriate help.) The "No longer protects whole document" seems irrelevant (or is trying to move the help/tooltip function into the UI). C. Word-compatible - (bug Bug 104668) Also missing help. I could not understand the discussion in bug 104668) Is this another case of "Use OpenOffice.org 1.1..."? (if enabled)? (maybe do not need to mention Word-compatible at all) D. "Render non-breaking spaces (NBSP) as standard-space-width (off for fixed size)" Also missing help. This is bug 41652. If I understand correctly then isn't it: Do not render non-breaking spaces as fixed-width space The "off for fixed size" seems like it should be in the help, not the UI. E. "Expand word space on lines with manual line breaks in justified paragraphs" ----> "Justify lines with manual line breaks (in justified paragraphs)" (could skip this change if too many changes already, but I believe the meaning of the proposal is easier to guess, while the current version is tough to follow) [1] https://help.libreoffice.org/24.2/en-US/text/shared/optionen/01041000.html?DbPAR=WRITER
(In reply to sdc.blanco from comment #0) > * better sequencing of options? Is is possible to put the more common/more important options first (and least important/common last)? For less common, guessing that "Use OpenOffice.org..." items could/should be grouped toward bottom, with the specialized cases (form, database, PDF) just before the "Use OpenOffice.." For importance, the "paragraph and table spacing" items at the top, followed by spacing options. Does anyone have enough knowledge to make an informed proposal? Otherwise, I could propose a patch centered around these ideas.
(In reply to sdc.blanco from comment #4) > (In reply to Heiko Tietze from comment #2) > > "Microsoft compatible Form menu" maybe. But I'd rather omit this option as a > > corner case and to clean up the dialog. > Does "clean up..." mean a different design/layout for the entire dialog? I mean to remove the GtkFrame "Global Compatibility Options" with the single checkbox (and have this one available only as advanced option). Leaving the other aspects for the design meeting.
Created attachment 189559 [details] MS Word 2004 Mac compatibility dialog Note the drop-down list box with the choice of app + version to collectively set compatibility options for. We could perhaps have that.
(In reply to sdc.blanco from comment #0) > * better sequencing of options? I would consider placing all options together and dropping the "like OOo 1.1" text in favor of the drop-down list box I attached an example of. > "Reorganize" is not a good word for the label. > Better label might be "Form dropdown menu like Microsoft". That option's phrasing is poor: 1. It describes a prolonged action rather than a setting (and it's probably a setting - have one kind of "organization" or another kind of "organization") 2. The term "organization" is not clear enough. Is this about the order of items on the menu? 3. "form menu" - is it a menu that's on forms? Some menu on the settings dialog, which is itself somewhat like a form? Is it the menu entitled "Form" on the main menu bar? and again - don't mention what the compatibility target is, that can be expressed using the drop-down listbox. > * general review of option labels for possible improvements/corrections > (e.g., bug 141676) I generally don't like many of them :-) * Instead of saying "Position objects like in OpenOffice 1.1", "Word-compatible trailing blanks" - we should try and say _how_ OOo positioned objects, _what_'s special about Word trailing blanks. * No commentary in parenthesis please, e.g. "(no longer protects X. You should do Y)" * We should not say "for compatibility" in the label for compatibility options. Of course its for compatibility. > * is the scroll box really needed? (i.e., general design/layout of dialog > can probably be simplified) That's certainly not a fun design. Perhaps consider two-line options? With the checkbox on the first line?
We discussed the topic in the design meeting and agreed to + hide single GUI option + reorganize the other, ie. OpenOffice 1.1 together + rename, ie. use verbs at the beginning + shorten text if possible, ie. "Tolerate..." without "for compatibility..." (In reply to Eyal Rozenberg from comment #8) > ... in favor of the drop-down list box I attached an example of. The patch would become more difficult and the dialog more crowded. Merging all ODF related options into one could be beneficial although it removes just a few items. Most of the other issues should be solved by the help.
Submitted a patch to remove the global options at https://gerrit.libreoffice.org/c/core/+/156911 But I wont touch the sort order. It's defined in include/unotools/compatibility.hxx and sw/inc/IDocumentSettingAccess.hxx with different variable names, but read as bit values in SwCompatibilityOptPage::GetDocumentOptions() and ::InitControls(). Leaving the labels for you, Seth or others. Change it in sw/uiconfig/swriter/ui/optcompatpage.ui.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1d4cd39262fb71f72311e33ac2bdb7d925be5d98 Related tdf#157006 - Remove global compatibility options It will be available in 24.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.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a4522ef5ce6a625054d83ec907aee07c156e94ed tdf#157266: fix crash related to tdf#157006 It will be available in 24.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.
(In reply to Heiko Tietze from comment #10) > But I wont touch the sort order. It's defined in... > include/unotools/compatibility.hxx and sw/inc/IDocumentSettingAccess.hxx Does this mean that if order is changed in sw/uiconfig/swriter/ui/optcompatpage.ui, then corresponding change in position is also needed in both SwCompatibilityOptPage::GetDocumentOptions() and ::InitControls(), found in sw/source/ui/config/optcomp.cxx (but no changes needed in the .hxx files)? > Leaving the labels for you, Seth or others. (In reply to sdc.blanco from comment #4) > A. "Consider wrapping styles when positioning objects" bug 157234 > D. "Render non-breaking spaces (NBSP) as standard-space-width (off for > fixed size)" According to bug 41652, the plan is to move this option to the character dialog (so, no need to change in Compatibility). Or, as suggested in bug 41652, comment 62, this might not need to be in the UI at all.
(In reply to sdc.blanco from comment #13) > Does this mean that if order is changed in ...ui, then corresponding change in > position is also needed in both ...cxx Not sure, some quick changes I made ended up in a mess. And if you check the wrong item it probably causes no immediate crash/test error but silently breaks documents. I chickend out at this point ;-).
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5debde6869e61d20148d16a9d47fb87dbf42f354 tdf#157006 shorten "Tolerate white lines..." label It will be available in 24.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.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/fed34532d998019b7bee3aff933e3b0ddeff9493 tdf#157006 update label change for "Tolerate white lines..."
(In reply to sdc.blanco from comment #4) > E. "Expand word space on lines with manual line breaks in justified > paragraphs" --> "Justify lines with a manual line break in justified paragraphs" https://gerrit.libreoffice.org/c/core/+/157118 Reasons: 1. Word space is always expanded in justified paragraphs, no need to mention it. 2. Put important action verb first. 3. "manual line breaks" can be misunderstood to imply that more than one line break can appear in a line. 4. Need to mention "in justified paragraphs", otherwise would suggest that all lines with manual breaks would be justified (independent of the selected text alignment). 5. 15% length reduction (in a long option label)
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0d375d059f52348d53858ff80e6a4d5372c7d71a tdf#157006 shorten "Expand word space..." label It will be available in 24.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.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/a83574c073321df45582cce99d7b811774438723 tdf#157006 update label change for "Expand word space..."
Note that we might need a similar dialog for other modules: 158063 (and I wonder if this is not also need for Calc at least).