Description: Grid and snap to grid can be enabled in Menu View -> Grid and Helplines. Why should the same option also be in a obscure place as Tools -> Options -> LibreOffice Writer -> Grid Actual Results: Grid and snap to grid can be enabled in Tools -> Options -> LibreOffice Writer -> Grid Expected Results: The options should be removed. There is no need for it. Reproducible: Always User Profile Reset: No Additional Info: Version: 5.4.0.0.alpha0+ Build ID: 88f561204d7cee25633df8117cc8d7e1ebd8e9ad CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-11_23:07:37 Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
There isnt a problem of having access to a feature in more than one place. :D
(In reply to Yousuf Philips (jay) from comment #1) > There isnt a problem of having access to a feature in more than one place. :D Wait a second. We talked about this and while your opinion is clear others agreed with removing the option from a "weird" place (tools > options > ... > grid) provided that view > grid > display is not a per document setting (based on tools > options). "Weird" because of this confusion: you are not sure why the option is doubled unlike menu/toolbar where the replication is not a question. So 2x +1 vs. 1x -1 for this change (simply remove the checkbox in tools > options).
After reading a similar ticket regarding Calc we should make Tools > Options... the general setting that defines if helplines are on by default and View > ... that toggles it on or off per document. So my proposal is to make the View option non-persistent. Removing UX, it's a bug IMHO, and NEW.
@Cor, @Stuart, @Adolfo: Do you guys have a take on this?
View options are in Tools. Also in Tools you can set on/of and more details. I would simply leave it as is.
Agree with Jay there is no problem with the duplication of controls on the menus. There are similar duplication for display or rulers, scroll bars, comments, etc. going to remove those as well? Things are consistent now that the controls (rather the associated .uno command) are assigned to both locations and function as simple toggles, with value recorded to user profile. The Tools -> Options -> [Module] -> View remains a useful aggregation of all the values on a single GUI panel distinct from button widgets on a menu. But if we were to make a major change, such that the View -> Grid and Helplines would be "per document" or "current session" and that Tools -> Options -> [Module] -> View would be the "general" case and persistent to profile--i.e. the settings for each new document/session: the implementation would have to apply to all similar UI controls, i.e. Rulers, Scroll bars, Comments etc. all the modal UI setting that are controlled from the View menu and duplicated on the Tools -> Options -> [Module] -> View; along with adding persistence, extending ODF spec to carry the setting with the document, duplicating the .uno commands (probably needed) for each UI element on View Done at that scope, very quickly not appealing and of minimal value. -1, WONTFIX for the whole issue.
Leaving it as is seems the best solution to me (maybe explain both settings in https://help.libreoffice.org/Common/Grid_1) At the time when I reported it I wasn't aware aware of the difference between Tools > Options > Writer > View (as a general setting) and View > Grid Lines (as current setting).
(In reply to V Stuart Foote from comment #6) > ... extending ODF spec to carry the setting with the document... Tools > Option should be the default setting when you start the program. View > Option toggles this property on/off or vice versa for the current session. Nothing has to be stored in a document. Most functionality is implemented like this except the gridlines in Writer. The confusion in this ticket results from an unclear definition of how those settings are stored. Keeping things as they are will not solve it.
(In reply to Heiko Tietze from comment #8) > Tools > Option should be the default setting when you start the program. Yes, no disagreement there. > View > Option toggles this property on/off or vice versa for the current > session. Nothing has to be stored in a document. Most functionality is > implemented like this except the gridlines in Writer... Sorry, but it does not behave that way. When you toggle a setting (either from View, or from Tools -> Options -> [Module] -> View) it is toggled immediately in the user profile and is persistent on next launch of the module. That is to be expected because it uses the same .uno command for both actions. A change would require duplicating the .uno command(s)--giving one persistent from Tools -> Options -> [Module] -> View menu as currently, and one transient i.e. not writing out to the profile registrymodifications.xcu from the View menu. Not to say something more flexible couldn't be worked up, but is it really needed? IMHO no.
(In reply to V Stuart Foote from comment #9) > Sorry, but it does not behave that way. When you toggle a setting (either > from View, or from Tools -> Options -> [Module] -> View) it is toggled > immediately in the user profile and is persistent on next launch of the > module. > > That is to be expected because it uses the same .uno command for both > actions. That's exactly what I mean. It works at some functions like described but not all. > A change would require duplicating the .uno command(s)--giving one > persistent from Tools -> Options -> [Module] -> View menu as currently, and > one transient i.e. not writing out to the profile registrymodifications.xcu > from the View menu. > > Not to say something more flexible couldn't be worked up, but is it really > needed? > > IMHO no. IMHO yes, otherwise this duplication is not helpful and adds confusion.
(In reply to Heiko Tietze from comment #2) > Wait a second. We talked about this and while your opinion is clear others > agreed with removing the option from a "weird" place (tools > options > ... > > grid) provided that view > grid > display is not a per document setting > (based on tools > options). "Weird" because of this confusion: you are not > sure why the option is doubled unlike menu/toolbar where the replication is > not a question. To be clear, kendy having no objection if both locations toggle the same setting isnt the same as him giving his thumbs up for it. The location isnt weird as it has been in the options dialog in the OOo days and is new to the menus in the last 1 year, as i mentioned in the discussion. (In reply to Heiko Tietze from comment #3) > After reading a similar ticket regarding Calc we should make Tools > > Options... the general setting that defines if helplines are on by default > and View > ... that toggles it on or off per document. So my proposal is to > make the View option non-persistent. Would have been nice if you gave the ticket number, so that bug could have been checked, but adopting Calc's per document grid/snap functionality into Writer isnt good and is confusing, especially with its broken functionality (bug 105749) and would require us modify ODF to save these per document settings as Stuart mentioned. We need to break up the per document settings and the global settings (bug 105751). (In reply to Telesto from comment #7) > At the time when I reported it I wasn't aware aware of the difference > between Tools > Options > Writer > View (as a general setting) and View > > Grid Lines (as current setting). There isnt a difference in Calc but not in Writer. (In reply to Heiko Tietze from comment #8) > Tools > Option should be the default setting when you start the program. > View > Option toggles this property on/off or vice versa for the current > session. Nothing has to be stored in a document. So you are suggesting View change it just for the session and not per document, as that makes less sense to me. > Most functionality is > implemented like this except the gridlines in Writer. The confusion in this > ticket results from an unclear definition of how those settings are stored. > Keeping things as they are will not solve it. The bug started off about removing the option in the options dialog and then you suggested we keep the option and change the behavior of the View menu option, which would require quite a lot of work for very little benefit. Ultimately the confusion to both us and users wont be solved properly until bug 105751 is implemented.