Description: There is a very serious UI problem with LO settings. The problem is that some of these settings are stored in the document/template, and some of them are stored in the application itself. **It is assumed you have a new LO user profile and LO uses US measurement units (specifically, inches) by default. We will test the Writer application.** Open "Tools > Options > LibreOffice Writer > General" and notice the following two settings: "Measurement unit" and "Tab stops". a) The value of "Tab stops", if you change it to a custom value and then save the document, will be stored in the document. b) ... While the value of "Measurement unit" is always stored in the application. c) Ah! And if you change the value of "Tab stops" to a custom value **without** saving the document, this custom value will be stored in the application and not in the document. And please notice that there are no hints to the user that these settings are stored so differently. And here is how confusing it can be in the real life: 1. Create an unsaved document. 2. Tools > Options > LibreOffice Writer > General: 1. Measurement unit = Change it from "Inch" to "Centimeter" 2. Tab stops = Change it from "1.25 cm" to "1.00 cm" HERE IS WHAT IS CURRENTLY GOING ON: * "Meas. unit" is stored in the application (as always) * "Tab stops" are stored in the application as well (this because we aren't going to the document at this moment of time, see the next step.) 3. Close the document without saving it. 4. Create another document. Notice the settings are the ones you have set up: "Centimeter" and "1.00 cm". This is fine. 5. Save the document. HERE IS WHAT IS CURRENTLY GOING ON: * "Meas. unit" is stored in the application (as always) * "Tab stops" are stored in the document (since you have saved the document) 6. Change the values to "Millimeter" and "6 mm" HERE IS WHAT IS CURRENTLY GOING ON: * "Meas. unit" is stored in the application (as always) * "Tab stops" are stored in the application as well (this because we aren't going to the document at this moment of time, see the next step.) 7. Close the document without saving it. 8. Open the saved file. Its values will be "Millimeter" and "10 mm" This is really confusing even for many experienced users who already aware of how this works. This is because the are many different settings and users **cannot** remember which of them are stored where. And so they cannot predict how some settings will change if you change the template. Or if you open the document on another computer. And this is much worse for many people who aren't so experienced. It seems to me that settings that are stored in the document and not in the application Solution-1: Should be "marked" as such. For example, instead of "Tab stops" it should be "Tab stops [D]" (where D stands for "document"). or Solution-2: They should be moved to a separate section. Steps to Reproduce: see above Actual Results: see above Expected Results: see above Reproducible: Always User Profile Reset: No Additional Info: see above
> The problem is that some of these settings are stored in the > document/template, and some of them are stored in the > application itself. The problem is that there is no hint to the user which of these settings are stored where.
> this because we aren't going to the document at this moment of time a typo. There should be > this because we aren't going to save the document at this moment of time
You request a solution but should report a problem with a use case. The tab stops clearly needs to be stored in the document - you want the defined 1cm on every workstation and all applications. Whether this distance is 1cm or 0.39" is a matter of the UI, internally we likely use Twip. In general, all default values are set-up via tools > options while document related properties are defined in other dialogs (which pick up what is defined as default). Admittedly we discuss from time to time where attributes belong to (for example the document language). But it's a per case solution. => WF (happy if you or others reopen)
The problem is that it makes harder for a user to understand what is going on. Sooner or later the user will face with a situation where some of his settings are "reset" and some are not, and he doesn't know why. Or a technical writer may write instruction about how LO should be configured in his organization, but he would prefer to avoid giving directions regarding settings that are already set up in the corporate template.
(In reply to John from comment #4) > The problem is that it makes harder for a user to understand what is going > on. In the process of deciphering the problem. My vision: The case 1. Open Writer 2. Tools > Options > LibreOffice Writer > General: 3. Measurement unit = Change it from "Inch" to "Centimeter" or if the default is Inch visa versa) 4. Tab stops = Change it from "1.25 cm" to "4.00 cm" 5. Press OK 6. Close the document 7. Open new document 8. Press Tab -> 4 cm jump and type something say AAA 8a. Save the document as ABC 9. Open a new document 10. Tools > Options > LibreOffice Writer > General: Measurement unit = Change it from "Inch" to "Centimeter" or if the default is Inch visa versa) 11. Tab stops = Change it from "1.25 cm" to "0.50 cm" 12. Press OK 13. Press Tab.. Jumps in 0,50 cm (OK) 14. Close the document.. (No save 15. Reopen the document ABC 16. Press Tab.. jumps still 4 cm 17. setting Tools > Options > LibreOffice Writer > General: Tab stop will be 4cm 19. Close the document 20. Open new document 21. Press Tab -> Tab stops are 0,50 cm 22. Open ABC again 23. Setting Tools > Options > LibreOffice Writer > General. Change tab top to 2 cm 24. Press OK 25. The content in the document moves 2 cm to the right The situation at step 17 and 21 rather contradicting. Tools > Options > LibreOffice Writer > General is an application setting.. But it shows the 'in document' setting, if the opened document has different tab stops embedded in the file (it's now not a 'application setting' but 'in document setting') That fact that the setting from "Tools > Options > LibreOffice Writer > General" being embedded in to document when used makes sense. (Else you get 23-25 effect) on different systems. You can't force the LibreOffice configuration defaults on a document (would change the layout) However there is no way of managing tab stops, if you're working on a document with embedded tab stops generated by Tools > Options > LibreOffice Writer > General setting. When moving the document system A with certain configuration, the system B using different defaults (regarding to Tab stops). The current behaviour surely confusing; counter intuitive and if you ask me wrong. There must be way to 'show' the in document tab stops.. Format -> Paragraph -> Tabs doesn't hold them Tab Stops created by "Tools > Options > LibreOffice Writer > General"(seems correct). There is simply lack of an dedicated dialog. And no 'in document' tab stops should be managed by "Tools > Options > LibreOffice Writer > General". That's the wrong location. What the proper location to access those tabs stops would be is a different question...
As an addition to Telesto's comment: This issue is not about tab stops only. Tab stops are just one case, but if I remember correctly, "Tools > Options" have more of them. This issue affects settings in other places as well. For example, most "View > Zoom" is stored in the application, but the view itself ("View > Normal" or "View > Web") is stored in the document. The whole idea of what I talking about is to make these things transparent for the user.
I think it is already reported, but I can't find, about to have some indication on every option to know if they are for file and not general. Something I think it's very helpful in general, without add new issues.
The more opinions the better. My take is a clear -1 / WF. Although implementing might not harm UX when done unobtrusively, eg. with a different font color for the labels, it's far from obvious to users what this information means. And developers have a hard time to implement it. Point is: all relevant information is stored in the document. If you find something which is not, report as an issue.
(In reply to Heiko Tietze from comment #8) > The more opinions the better. My take is a clear -1 / WF. Could please clarify what you're rating with -1 precisely . You're right about down voting comment 3. However, I don't think that that's being the topic. Talking past each other isn't really helpful. > Although implementing might not harm UX when done unobtrusively, eg. with a > different font color for the labels, it's far from obvious to users what > this information means. And developers have a hard time to implement it. Me having surely totally different understanding of the topic. So yet again not following.. > Point is: all relevant information is stored in the document. If you find > something which is not, report as an issue. True; but is this the topic? ---- The case - as far I'm reading the request of the OP (Or I'm yet again talking about something totally different or different perspective) I'm limiting myself to 'Tabs-stops' for now (admitting the scoping being larger) They OP poster deploys systems with document templates. Sometimes the user wants a different tab stop setting compared to the embedded one. So you can point to: Tools > Options > LibreOffice Writer > General. However if you change the setting there, it doesn't only affect the only the opened document, but all new documents created in LibreOffice where no explicit tab stop being defined I do think that should be possible to list all the in document defined settings. Which seems to be practical for authors of templates too. You else might be incident include something you didn't think off. As those are being introduced by LibreOffice General settings.. Tools > Options > LibreOffice Writer > General is a global setting, for all new documents. It is not the tool for CHANGING/EDITTING the pre-existing Tab stop setting for a single document. Showing all embedded settings could be done in File -> Properties; which could look like the Style Inspector approach. Where talking about things like * Default Printer * Tab Stops * Multipage - Single Page view * Zoom-level??? * Last position in Document (I recall this being stored, or I'm I making this up?) * Other additional options which are also stored in document (which needs checking the ODT specifications, I guess). Is there any documentation (full list) of type of setting can be embedded in ODT? It also aligns - in my perception - with my request for showing the File Format Version somewhere in the Document Properties window.
To summarize the problem: Some settings are stored in the application; some in the document; and some in the document if you save it afterwards, and in the application otherwise. The problem is that LibreOffice does not differentiate these settings for the user, and so you do not know if the current value of the setting that you are about to change is "inherited" from the application or is stored in the document, and you do not know where it will be stored after you change it.
The previous comment is not precisely accurate. Here is a fixed version: Some settings are stored in the application; some in the document; and some in both the application and the document if you save the document afterwards, and only in the application otherwise. The problem is that LibreOffice does not differentiate these kinds of settings for the user, and so you do not know if the current value of the setting that you are about to change is "inherited" from the application or is stored in the document, and you do not know where it will be stored after you change it.
@Mike Would be nice to have your perspective on the matter too.
(In reply to Telesto from comment #9) > Could please clarify what you're rating with -1 precisely I doubt that giving feedback on where options are stored a) is of practical use, b) can be done unobtrusively, c) would be possible with a reasonable amount of work. Regarding a) I said, _all_ options that are relevant to reproduce the layout pixel-perfect cross-platform and cross-application are stored in the document. The tab stop is such a value while the unit is not. We may have bugs here. In respect to b) it might be a different color for the label or a small icon/symbol next to it. In any case it first of all clutters the UI and secondly makes ordinary users who don't care about the options wonder what this indicator is meant for. And last but not least, c) is important. There might be cases where a setting is stored only in some cases in the document. Many of what is configured in tools > options can be tweaked per document at other dialogs. An example is your locale which defines whether documents are letter or A4 but ultimately it's the page style what defines the layout. Admittedly, if all my concerns are neglectable it would give some confidence in what you configure and how it works.
(In reply to m.a.riosv from comment #7) > I think it is already reported, but I can't find Same with me. This is *definitely* a must. Having document-specific properties in Options is plain wrong. People should not be expected to look for such options there, and you will not find a "this is intuitive" reason for such placement; no "UI simplification" is an excuse for that. In case when there are defaults (suitable for Options dialog), they should be limited to the "defaults" in Options, and should never suggest to also/alternatively modify current document's properties. There should be document-specific location for its properties - likely in File->Properties (but it's debatable, of course); the two locations could have inter-links, like buttons "Default..." in File->Properties dialog, pointing to related Options tab.
To Mike and Heiko: I agree that changing how settings are currently organizing would be a large amount of work. Probably too large. But what is much simpler is to add [D] after each setting that is stored per document. Example 1: Tools > Options > LibreOffice Writer > General: * Measurement unit: ... * Tab stops [D]: ... Example 2: View: * Normal View [D] * Web View [D] D stands for "document", of course. Another option is to use asterisk* instead of [D]. Of course, [D] (or asterisks) will clutter up the user interface a bit. But in my personal opinion this the case where a little cluttering is justified. The main thing about user interfaces is that they should be understandable.
I staunchly support "solution 2". I claim that _no_ setting in an application's options dialog should be a document- or file-specific setting. The dialog should _only_ have application-level settings, inspecific to a single file, which are saved in the app's configuration files and apply to all relevant documents. I claim that this is what users expect; it is what's common in other applications; it is a reasonable, almost necessary, separation. I therefore disagree that the problem can be resolved by an indication or hint of what gets stored where. Instead of hinting or indicating we should just avoid this ambiguity from the get-go. Document-specific settings belong in document properties, or other document-specific dialogs. I myself had not even realized until the other day that this was even the case! And I consider myself to be a somewhat experienced user... That all being said... : * I recognize some settings are app-level defaults, which are saved in documents since the documents make a copy of those settings. For example, default Western language to use, or tab stop size etc. * There may be some settings for is ambiguous whether they should exist at document-level or app-level, and the way the dialog is structured has allowed the maintenance of this ambiguity without having to decide this way or the other, and without duplicating the default and per-document setting. ... and those need special care. -------- (In reply to John from comment #15) > I agree that changing how settings are currently organizing would be a large > amount of work. Probably too large. It's a lot of work, but not "too large" IMHO. Why? Because: 1. After all, it's just moving settings between dialogs. I mean, it's not about re-implementing the mechanisms affected by those settings or touching them at all. Dialog redesign is significant work, but it's not like there could be all sorts of arcane bugs, or perf issues, or refactoring hairy code etc. 2. It doesn't all have to happen at once. If targets for different settings are located, or created, they could have settings moved there gradually. We're in a messy situation already, so a partial move doesn't make things that much more messy 3. It doesn't all have to happen at once II: Since the options dialog is a rather stable entity, a move could be worked on gradually in some branch for a while before being rebased on the latest development version. > But what is much simpler is to add [D] after each setting that is stored per > document. I'm not sure it's simpler. I mean, it may be simpler to implement, but it would be quite a user-unfriendly eyesore IMO. So again - "solution 2": Let's separate app settings from document settings. Finally - I've rephrased the title to reflect the fact that the solution has not yet been chosen definitely, and to mention "Options dialog" explicitly. I also suggest that we change the severity from "enhancement" to "major".
(In reply to Telesto from comment #9) > Is there any documentation (full list) of type of setting can be embedded in > ODT? I agree that a list per-document settings would be very useful here, and that the best solution would be to have per-document settings set outside of the Options dialog. If we are going that way, we can create more focused bug reports on the per-document settings that need to be "extracted" from the Options dialog, and make them block this bug report. Some elements might feel more like a priority. Adding a visual indicator for each setting feels like a band-aid, and will add unnecessary clutter when we could instead make it unobtrusively clearer by keeping as many per-document settings as possible _out_ of the Options dialog.
(In reply to Stéphane Guillou (stragu) from comment #17) > I agree that a list per-document settings would be very useful here... > > If we are going that way, we can create more focused bug reports on the > per-document settings that need to be "extracted" from the Options dialog Please go ahead and start creating such bug reports, without blocking on a "list per-document settings", which would require some extensive analysis for no real benefit. If one sees a single such option, and points to it, like e.g. here in the comment 0, it's enough reason to file it, and act on it, which would gradually get the end goal.
Marking as NEW as something clearly needs to be done according to comments. Some of these issues are bound to be inherited from OOo.
Just adding my support for removing any document-specific settings from Tools|Options. It’s just too confusing and adding indicators or colours would be a poor fix.