As an 'edit file' menu item is being request in bug 80536, i would like to suggest the default disabling of it icon from the standard toolbar because. 1) i dont know many people who use the feature 2) the toolbar is already cluttered and reducing its size means we can put more commonly used buttons in it 3) it will still be possible for those that use it, to re-enable it
+1 from my side. Any objections?
As jorendc +1'ed, i'm setting it to NEW.
I am against stuffing commands to the already cluttered menus. The correct procedure here would be dynamically hiding the “Edit file” icon in new and editable documents, and showing it only when it’s necessary, i.e., when you open a read-only file. Also, the menu entry you suggest in bug 80536 makes absolutely no sense in the View menu.
Well i think dynamically hiding the icon would be a great idea if the standard toolbar wasnt unified across multiple documents. Presently if i have one edit mode document and a second read-only mode document open and i change the standard toolbar in one, it will change in the other. Regarding bug 80536, after looking over the menus again, I guess it might be better to be included in the Edit menu. When i suggested it be in the View menu, I was taking it from the point of view that when its in read-only mode, you are viewing the document in that manner, as the view of the interface changes, similar to how the view of the interface changes when you go for print or web layout.
i know i'm weird, but i click on the Edit File button a lot to make an editable document read-only and thereby prevent myself from accidentally modifying a document that i never intend to modify, and also to remove the spell-checker underlines that distract when just reading a document. also, it prevents nag dialogs when opening the same file with multiple LO installations, but probably that is something only developers/QA do...
people know it and use it when attachments from mail are opened as read only. Are you available to help all those people Jay, often not handy in finding new stuff in menus :)
Okay, to many -1's :-). I knew this proposed would always 'step on someones toes' :-). Sadly I think this kind of 'toolbar cluttering' and 'keep is at it is because _some_ users will miss it' is one of our weaknesses, instead of a strenght (called 'stability'). Is there _any_ feature in the pipeline to analyse the toolbar/menu/shortcut usage of LibreOffice :-). I think we can make better decisions for what icons we should have in our toolbar and at the top of our menus. Thanks for all the feedback. I really appreciate that :-)! Kind regards, Joren
(In reply to comment #5) > i know i'm weird, but i click on the Edit File button a lot > to make an editable document read-only and thereby prevent myself > from accidentally modifying a document that i never intend to modify, > and also to remove the spell-checker underlines that distract when > just reading a document. No i dont think it is weird, as i had thought people might use it for better reading, but then why not just use page/print preview as it has similar no edit functionality. > also, it prevents nag dialogs when opening the same file > with multiple LO installations, but probably that is something > only developers/QA do... Yes for QA i always get nagged by that issue as i'm opening the doc in 6 different versions and there isnt any file double-click option to open in read mode. :) (In reply to comment #6) > people know it and use it when attachments from mail are opened as read only. > Are you available to help all those people Jay, often not handy in finding > new stuff in menus :) I would love to hear the exact scenario that users are opening attachments in read only, as when attachment come to me in thunderbird, i click open and it opens, never remember having a read only option for such attachments. Well it is not a new feature as its inherited from OOo and its not like i'm asking that it be removed from the toolbar, just that its disabled by default similar to 'Find & Replace' and 'Zoom', so that space can be opened up for more used functions like 'Insert Picture' or 'Insert Comment', IMHO. And for all those who might be searching through the menu for the feature, Ubuntu's searchable HUD has got your back. :)
(In reply to comment #8) > I would love to hear the exact scenario that users are opening attachments > in read only, as when attachment come to me in thunderbird, i click open and > it opens, never remember having a read only option for such attachments. For example on Fedora, clicking an attachment in Thunderbird to open it in LO, Thunderbird stores the attachment as a read-only file in /tmp, then calls LO to open that read-only file. (Which is the scenario for which <http://cgit.freedesktop.org/libreoffice/core/commit/?id=b9ecec7c74687ed5a9470cffb7d02e0e6e83107e> "Allow for editing of read-only documents" was introduced, which relies on easy availabiliy of the "Edit File" toggle in the UI.)
Yes you are correct that thunderbird on linux and windows does open attachments in read only mode. I normally save documents that i wish to edit to a particular location, as the default open location from with a browser or email client is always the temporary folder. Well i guess Adolfo's suggestion of dynamic hiding would be the best thing then. I personally have it icon hidden and if i open a read only document, the icon doesnt appear, so i can turn it into edit mode, as there is also no menu option for it.
Ideally, LibreOffice would present an infobar [1] with any read-only document and have an entry in the menubar as well (perhaps with a keyboard shortcut for quick access). That should hopefully take care of what seems to be the common use-case -- editing read-only documents -- and leave room for less common use-cases -- using "read-only mode" to read a document -- as well. [1] https://wiki.documentfoundation.org/Design/Guidelines#Infobar
I think that sounds perfect as it covers all the bases and for users who use it alot, they can easily re-enable the icon in the toolbar or use the keyboard shortcut ( thats for you Michael :) ). By the way, has the infobar been implemented yet, as i had submitted another bug (bug 78186) about an infobar appearing when a file is opened and fonts are missing.
(In reply to comment #12) > By the way, has the infobar been implemented yet http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=infobar
Summary amended for clarity. The Thunderbird issue pointed out in comment 9 comes up quite a bit on the AskLO forum, as do other questions of files opened from the web and Outlook that get pointed to this button e.g., - http://ask.libreoffice.org/en/question/578/ - http://ask.libreoffice.org/en/question/1228/ - http://ask.libreoffice.org/en/question/3998/
(In reply to comment #13) > http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=infobar Seems like its implement from the link but havent come across a single instance for when it shows. (In reply to comment #14) > - http://ask.libreoffice.org/en/question/578/ > - http://ask.libreoffice.org/en/question/1228/ > - http://ask.libreoffice.org/en/question/3998/ 578 - says to click a button, but the image that should show which button is missing 1228 - says to click the 'edit file' button 3998 - suggests the user should click the save and not open button in their browser From these examples, even when the 'edit file' button is there, people still dont know to press it, thats why a infobar is still a great idea.
Created attachment 103007 [details] how the fullscreen hovering button appears As the infobar maybe a hard thing to get going, i think the best possible thing would be to have the 'edit file' icon with title appear in its own toolbar, similar to the 'full screen' option in print preview mode.
*** Bug 80774 has been marked as a duplicate of this bug. ***
I suggest the following text for the infobar: __________________________________________________________________________ This document is open in read-only mode. [ Enable editing ] [X] Once the document is editable, the “Edit File” icon would appear in the toolbar, but renamed to “Toggle Read-Only Mode” (as per bug 80774).
Yes i think the infobar text is good. I think this infobar should only appear when a document is opened in read-only mode and not when a user enables read-only mode from the menu or toolbar.
Although I do not fully understand the discussion about infobar, I want to clarify how I use read-only so that can be taken into account in whatever y'all decide to do. 1. 90% of the time: I have a file open read-write over the network on my laptop. The laptop will not sleep while the file is open. If I change the file to read-only, the file handle will be closed. (Well, it should be, but I believe there is a bug where it does not actually close.) 2. 5% of the time: File is open read-write by someone else (me on a different machine). I want to at least look at it. 3. 4% of the time: I have the file open read-write, but I want to open it read-write from another machine, but without losing state on the first machine. (Although the file might change under me -- this should be checked by the program, btw, when switching to read-write from read-only.) 3. 1% of the time: I do not have write permission on the file.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6270de939d5ee51b61dc4ac02c52f1d9b5b1e47 fdo#80538 Show an infobar when document is in read-only mode The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Please test and report any issues you find (create a new bug and CC me).
Thanks Samuel for the patch. I still have to wait for a daily build to come out to test it. :) I wanted to make sure that the infobar only appears when the document is first opened in read-only mode, as it doesnt need to appear if a user enables read-only mode from the menu. Also, was the clickable text '[ Enable editing ]' also added, so users could enable edition from the infobar. If that is not possible, then instructions to enable editing should also be added with the text like 'To enable editing, click the Edit Mode entry in the Edit menu.' And i think its best that we hide the icon rather than remove it, so that users who use it alot, like Stahl, can easily re-enable it again. Hopefully when the shortcut key for it is added, which was a part of bug 80536 that wasnt completed, Stahl will be more comfortable using that. :D
Created attachment 105425 [details] How the infobar looks in Writer
See attached screenshot for how it looks like. The infobar is only shown when a document is opened read-only, not when you manually toggle the read-only state. I'll have a look at adding a shortcut to the edit menu entry, I think then we don't need the edit button in the toolbar anymore.
Nice!
Thanks for the screenshot. It looks great. Yep the shortcut will likely help people used to shortcut keys (fingers crossed that Stahl is one), but wont help people who prefer clicking toolbar buttons. :)
Was curious if you had thought about the logic in which the infobar needs to be closed as the user has clicked the menu entry or pressed the shortcut key for read-only mode. Highly doubt a user will click the menu entry when the infobar is there, but believe users familiar with the shortcut key will likely press it rather than move the mouse.
(In reply to comment #28) > Was curious if you had thought about the logic in which the infobar needs to > be closed as the user has clicked the menu entry or pressed the shortcut key > for read-only mode. Highly doubt a user will click the menu entry when the > infobar is there, but believe users familiar with the shortcut key will > likely press it rather than move the mouse. It should.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a2c6ce60b9b9cc15a3a7ab01abcaf4e3f3bfe270 fdo#80538 Add (hidden) edit icons to the toolbar again The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Submitted patch to re-add missing separators. https://gerrit.libreoffice.org/#/c/11523/
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=db3d60ba093d3f2b98f46eb159cf20bdf6760ab5 Related fdo#80538 Re-adding toolbar separators The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This bug fix comes with LibreOffice 4.4 (release notes https://wiki.documentfoundation.org/ReleaseNotes/4.4) LibreOffice will now display an infobar to indicate visibly when a document is being opened in read-only mode. This infobar replaces the “Edit file” icon in the main toolbar, as its labeling and usage patterns proved confusing for users. Activation and deactivation of read-only mode is also available from within the menu Edit ▸ Edit Mode or through the keyboard shortcut Ctrl+⇧ Shift+M. See a graphic of the work: https://wiki.documentfoundation.org/File:Read-only_infobar.png
Sorry, but I find this fix to be inadequate. There are a number of things I don't like: 1. The info bar occupies too much vertical real estate. In most cases vertical real estate is at a premium. This means that users will want to get rid of this as soon as they see it. How do you get it back if you later are not sure what it said or permitted? No obvious way. 2. Let's say the file is locked by another process somewhere. I agree to edit the file read-only (we still have a problem of the meaning of "edit", btw -- in my mind "edit" does not imply read-write permission, just the ability to look at the file). Then I later go and remove the lock, e.g. by closing the other program that had it locked. Now, how do I change the mode to read-write? No obvious way. Nothing in the 'File' or 'Edit' menus. (BTW, if I am not "edit"ing the file, according to the apparent LO meaning of "edit," how come there are still options in the "Edit" menu that are not grayed out?) So, I would say that now the read/write functionality is even less discoverable than before, and certainly no clearer. The only plus I see is an initial notification that the file is being opened read-only. At the least, a menu entry should be created, probably in the "File" menu that is something like "Re-open file read-write". It would also make sense, when the file is already read-write, to have a File menu entry that replaces that one and says "Re-open file read-only." In addition, the infobar notification should mention how to change to read-write after the infobar is dismissed.
Oop, sorry, I did not notice that you said: "Activation and deactivation of read-only mode is also available from within the menu Edit ▸ Edit Mode"... This option is NOT available in the copy of calc I am looking at on win 7 x64. I would also recommend that the term "Edit Mode" is overly vague, i.e. not transparent to the naive user. A better term would be what I suggested above, or else something like "Toggle Read-only Mode" "Edit Mode" does not imply anything about changing read-only state. Any mode at all related to editing the document is an "edit mode."
I should also have said that I think a more appropriate place for the read-only mode toggle menu entry is the File menu. It relates to the file; it is not an editing tool.
Hi pb, (In reply to pb from comment #34) > 1. The info bar occupies too much vertical real estate. In most cases > vertical real estate is at a premium. This means that users will want to > get rid of this as soon as they see it. How do you get it back if you later > are not sure what it said or permitted? No obvious way. As the formatting toolbar is hidden when a user opens a document in read-only mode, not much vertical real estate is taken up. If a user dismisses the notification, they are able to change to editing mode through the menu entry or through the right-click context menu. > 2. Let's say the file is locked by another process somewhere. I agree to > edit the file read-only (we still have a problem of the meaning of "edit", > btw -- in my mind "edit" does not imply read-write permission, just the > ability to look at the file). Then I later go and remove the lock, e.g. by > closing the other program that had it locked. Now, how do I change the mode > to read-write? No obvious way. Nothing in the 'File' or 'Edit' menus. > (BTW, if I am not "edit"ing the file, according to the apparent LO meaning > of "edit," how come there are still options in the "Edit" menu that are not > grayed out?) To "edit" something is to change the look/contents of something, so you can not edit a file in read-only mode, you can only view it. The 'Edit' menu has entries like copy, select all and find which dont involve editing the file. (In reply to pb from comment #35) > This option is NOT available in the copy of calc I am looking at on win 7 > x64. I would also recommend that the term "Edit Mode" is overly vague, i.e. > not transparent to the naive user. A better term would be what I suggested > above, or else something like "Toggle Read-only Mode" "Edit Mode" does not > imply anything about changing read-only state. The entry is there for me on Linux. If you can paste your version number from the Help > About LibreOffice dialog, maybe we can see what might be the problem for you. 'Read-Only Mode' was suggested by Adolfo in bug 80536 comment 9, but no progress was made after that on changing it. > Any mode at all related to editing the document is an "edit mode." I think you are mixing up 'mode' with 'function'. When you edit a document, you are performing various functions on the document (e.g. adding a table, making some text bold) which you are able to do when the document is in edit mode or non-read-only mode. (In reply to pb from comment #36) > I should also have said that I think a more appropriate place for the > read-only mode toggle menu entry is the File menu. It relates to the file; > it is not an editing tool. You had already suggested putting it in the File menu as "Re-open file read-write", but the problem there is that you are not re-opening the file, you are simply changing the state of an already opened file. This feature is not only for when a file is being loaded, it is also used when a user wishes to disable editing of the document while they are reading through it (like Michael in comment 5).
(In reply to Jay Philips from comment #37) > Hi pb, > > (In reply to pb from comment #34) > > 1. The info bar occupies too much vertical real estate. In most cases > > vertical real estate is at a premium. This means that users will want to > > get rid of this as soon as they see it. How do you get it back if you later > > are not sure what it said or permitted? No obvious way. > > As the formatting toolbar is hidden when a user opens a document in > read-only mode, not much vertical real estate is taken up. If a user > dismisses the notification, they are able to change to editing mode through > the menu entry or through the right-click context menu. But, when it is there it takes up a lot more real estate than it needs to. And, it is visually obvious that it is wasting real estate, regardless of whether the user realized that something else was missing. Thus, the tendency is to get rid of it as soon as possible, but later there may be buyer's remorse, not realizing that now the so-called "Edit" functionality button is nowhere to be found. So, I do not yield on that criticism. > > > 2. Let's say the file is locked by another process somewhere. I agree to > > edit the file read-only (we still have a problem of the meaning of "edit", > > btw -- in my mind "edit" does not imply read-write permission, just the > > ability to look at the file). Then I later go and remove the lock, e.g. by > > closing the other program that had it locked. Now, how do I change the mode > > to read-write? No obvious way. Nothing in the 'File' or 'Edit' menus. > > (BTW, if I am not "edit"ing the file, according to the apparent LO meaning > > of "edit," how come there are still options in the "Edit" menu that are not > > grayed out?) > > To "edit" something is to change the look/contents of something, so you can > not edit a file in read-only mode, you can only view it. The 'Edit' menu has > entries like copy, select all and find which dont involve editing the file. You can quibble about definitions all you want. To me, edit means access the file. A lot of naive users may not understand the finer points of LO English, and realize that "Edit" on LO English means "be able to save the spreadsheet to the same file." "Edit" can mean a lot of things. Among the things it can mean is what you assert it does mean. However, that sense may not be the sense that is obvious to the naive user. It's not enough that it be TRUE that "edit" means that; it is also desirable that it not mean anything else. In other words, it's important that the term be unambiguous. A term such as "change file state to read-write from read-only" is fairly unambiguous, though unfortunately rather wordy. "Change to read-write" maybe. I happen to like "toggle read-only", but that may be obscure for some. I don't yield on that point, either. > > (In reply to pb from comment #35) > > This option is NOT available in the copy of calc I am looking at on win 7 > > x64. I would also recommend that the term "Edit Mode" is overly vague, i.e. > > not transparent to the naive user. A better term would be what I suggested > > above, or else something like "Toggle Read-only Mode" "Edit Mode" does not > > imply anything about changing read-only state. > > The entry is there for me on Linux. If you can paste your version number > from the Help > About LibreOffice dialog, maybe we can see what might be the > problem for you. 'Read-Only Mode' was suggested by Adolfo in bug 80536 > comment 9, but no progress was made after that on changing it. Version: 4.4.0.1 Build ID: 1ba9640ddd424f1f535c75bf2b86703770b8cf6f Locale: en_US > > > Any mode at all related to editing the document is an "edit mode." > > I think you are mixing up 'mode' with 'function'. When you edit a document, > you are performing various functions on the document (e.g. adding a table, > making some text bold) which you are able to do when the document is in edit > mode or non-read-only mode. No, I am not mixing up 'mode' with 'function'. I would rather assert that you are, because on the one hand in the infobar "Edit" refers to the read-write state of the file, while in the "Edit" menu, it refers to functions that can be performed on the document. Again, this is semantics. The point is that terms like "edit mode", while they can mean what you are saying they do, are also ambiguous and can mean something else to someone else, especially a naive user, who may not realize what kind of modes are available. For example, in a spreadsheet, there is a difference between navigation mode and cell-entry mode, where typing the same thing might have different effects, depending on the mode. Also, a common mode option is toggle between text-insert and text-overwrite, and most keyboards have a way to toggle that mode. That could just as easily be what a naive user might think "edit mode" means. Let me put it this way. There is a mapping between meaning and words. You are saying the meaning you want maps to the words you want. I tend to agree, BUT I am saying, that is not a 1-1 map, which means the inverse map (words to meaning) can be confusing to the user. So, I am striving for more unambiguous language. > > (In reply to pb from comment #36) > > I should also have said that I think a more appropriate place for the > > read-only mode toggle menu entry is the File menu. It relates to the file; > > it is not an editing tool. > > You had already suggested putting it in the File menu as "Re-open file > read-write", but the problem there is that you are not re-opening the file, > you are simply changing the state of an already opened file. This feature is > not only for when a file is being loaded, it is also used when a user wishes > to disable editing of the document while they are reading through it (like > Michael in comment 5). Ok, I used that locution only because in previous incarnations the only way I could determine to change the read-only state was to re-open the file. A better choice would be "switch to read-only" and "switch to read-write". In any case, it should be in the File menu, not the Edit menu, again, because the Edit menu has to do with functions on the document, while the File menu has to do with functions on the underlying file, which includes the "edit mode" as you call it, and which I call whether the file is open read-only or read-write. Also, I would point out that as long as there isn't too much clutter, it can appear in multiple places without loss of generality. That has the benefit that a user is more likely to find it in the place that makes sense to him.
It takes up 40 pixels of height, the same height as the formatting toolbar, so i find its size just fine. It is a notice that users can choose to ignore, especially when they have read those same 8 words previously, but it is definitely better than the 'Edit File' button that was previously in the toolbar. If you'd like to propose an improvement to this mechanism of opening documents already in use, please open a new bug report as no further changes will be happening within this one. If you think that edit means accessing a file then i'm sorry but you dont know what edit means. This is not LO English, this is English. The definition of edit is "to make changes, correct mistakes, etc., in (something written)" ( http://www.merriam-webster.com/dictionary/edit ). If naive users do not know what edit means, then there isnt much we can help them with it. About 'Edit Mode' not appearing in your menu, i'd suggest clearing your profile or resetting your menu (Tools > Customize > Menus tab > Reset button). The main arguments i see that you have is the wording of the entry in the menu and which menu heading it should be under. The wording of entries in the menus isnt always the most meaningful wording possible and is always open to improvement, which is why i agree that it would be better as 'Read-Only Mode' but its not possible for an entry to be changing from one wording to another (e.g. "switch to read-only" to "switch to read-write"). If you see bug 80536, i had initially thought 'View' was the best location for the entry but after various debates it is present in 'Edit'. Placing the entry in two locations is not an option in my view.
Indeed, resetting the Edit menu brought the "Edit Mode" item into existence. Thanks. Since to my knowledge, I had never customized that menu, it is however a bug that it did not appear when I upgraded or reinstalled LO. Meanwhile, I also discovered something I had not realized before, namely that I can rename that menu item to anything I like, for example "Gzorniplotz." However, I chose to rename it "Toggle Read-Only". So, for those who foolishly agree with me that "Edit Mode" may not be the best name for this function, or, er, mode, the name is customizable. Pursuing this train of thought, I figured I could also add the item to the File menu, as I prefer. Searching linearly through all commands (since there is no search functionality I could find for customization), I discovered a command interestingly called "Toggle Edit Mode" in the first category "Internal." Surely, this is what I want, because we have established that "Edit Mode" can mean one thing and one thing only to those who actually know what the words "edit" and "mode" mean. So, I happily added this to my File menu. But, alas and alack, some long-vanished gremlin developer decided to make a mockery of the English language, and it turns out that "Toggle Edit Mode" actually has nothing to do with toggling edit mode, but rather something else that has nothing to do with a mode, apparently, but only with a function. Apparently that function is to display formulas rather than their results so that they can be edited, er, I mean not "edited" but rather modified. Maybe it would be desirable to have consistency in what "edit mode" means in LO English? It turns out that "Edit Mode," not "Toggle Edit Mode" is found in the "Documents" category of commands. We should note that to toggle Edit Mode, one should use "Edit Mode", and to toggle the cell edit mode, one should use "Toggle Edit Mode". I'm sure that's perfectly clear to anyone who has studied English for at least a semester course. So, in the end, I can actually have the menus as I think they should be, so thanks for pointing me to where I could discover that. As for the infobar, I still think it's too big, and I still think it should at least tell the user where to change things once the infobar is dismissed, but since it is now set in stone, hopefully I can figure out how to disable it altogether.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=02f76dec4c54ec7fb28729941c7044307058665a Re fdo#80538: Remove read-only infobar after "Save As..." It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b693b64dbcf1be2598051773805b8cdc2d8297aa&h=libreoffice-4-4 Re fdo#80538: Remove read-only infobar after "Save As..." It will be available in 4.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to pb from comment #40) > Indeed, resetting the Edit menu brought the "Edit Mode" item into existence. > Thanks. Since to my knowledge, I had never customized that menu, it is > however a bug that it did not appear when I upgraded or reinstalled LO. Glad that helped. > Meanwhile, I also discovered something I had not realized before, namely > that I can rename that menu item to anything I like, for example > "Gzorniplotz." However, I chose to rename it "Toggle Read-Only". So, for > those who foolishly agree with me that "Edit Mode" may not be the best name > for this function, or, er, mode, the name is customizable. Yes LO is very customizable for people who want to change it to their own liking. > Pursuing this train of thought, I figured I could also add the item to the > File menu, as I prefer. Searching linearly through all commands (since > there is no search functionality I could find for customization), I > discovered a command interestingly called "Toggle Edit Mode" in the first > category "Internal." Surely, this is what I want, because we have > established that "Edit Mode" can mean one thing and one thing only to those > who actually know what the words "edit" and "mode" mean. So, I happily > added this to my File menu. But, alas and alack, some long-vanished gremlin > developer decided to make a mockery of the English language, and it turns > out that "Toggle Edit Mode" actually has nothing to do with toggling edit > mode, but rather something else that has nothing to do with a mode, > apparently, but only with a function. Apparently that function is to > display formulas rather than their results so that they can be edited, er, I > mean not "edited" but rather modified. Maybe it would be desirable to have > consistency in what "edit mode" means in LO English? > > It turns out that "Edit Mode," not "Toggle Edit Mode" is found in the > "Documents" category of commands. We should note that to toggle Edit Mode, > one should use "Edit Mode", and to toggle the cell edit mode, one should use > "Toggle Edit Mode". I'm sure that's perfectly clear to anyone who has > studied English for at least a semester course. Yes i've gone through the same hassle of trying to understand the labeling added to entries in the customization dialog and them being organized in categorizes that i found it strange that it would be put in. The main problem is that the labeling has been set according to how it appears in the menu, so the label for inserting an image was previously 'From File' as it was in the menu as Insert > Picture > From File. So the main problem is that you dont see context in the label. > So, in the end, I can actually have the menus as I think they should be, so > thanks for pointing me to where I could discover that. As for the infobar, > I still think it's too big, and I still think it should at least tell the > user where to change things once the infobar is dismissed, but since it is > now set in stone, hopefully I can figure out how to disable it altogether. As previously stated, it is not set in stone but cant be changed in this bug report. So please create bug reports for the menu label change (which i did already agree can be improved) and the infobar message change so it can be looked into.
*** Bug 61356 has been marked as a duplicate of this bug. ***