In Calc, after clicking the Save icon for a modified existing .ods file, the icon is not greyed out after the save has completed. This used to happen in 5.0 "Allow to save document even when the document is not modified" setting has NOT been set/selected. First noticed in 5.1 Beta 2 and still exists in 5.1 rc1.
I confirm bug under Win8.1 x64 5.2.0.0.alpha0+ Build ID: 51a5dfd783bfc1efc52a791aab4114039581252f Threads 4; Ver: Windows 6.2; Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-04_10:49:33 Locale: it-IT (it_IT) bug is not limited to Calc and affects Writer too. works fine in LibO 5.0.3.1 regression, needs bibisecting
It's a known issue and will be adressed until RC2.
No need to bibisect
*** Bug 96601 has been marked as a duplicate of this bug. ***
The current plan is to change the icon of that button, to indicate whether the document is modified. Completely disabling the button as before is not planned - so WONTFIX (for now). More details are at http://lists.freedesktop.org/archives/libreoffice/2015-December/071519.html Users that not happy with the new behavior, are free to change it via expert config: Type "SaveToolbarController" in the search field and hit Enter. To allow disabling the button, but still have the dropdown there, change "Controller" to "com.sun.star.comp.framework.GenericPopupToolbarController", and "Value" to ".uno:SaveAsMenu". Leaving "Value" empty will bring back the old simple button (without the dropdown). Note that the design team wants also to change the "allow always saving" thing to true by default, so at some point there will be need to manually set it to false (search expert config for "AlwaysAllowSave").
I've just upgraded from LO 5.0.3.2 to 5.1.0 RC1 and discovered this change in SAVE button action. I really miss the simple indication as to whether the file content has changed or not. It was also one of the things I disliked about MSO. Re suggested workaround, which file do I need to modify? (It looks quite tricky for a basic user like myself). I've looked at the Minutes of the Design Hangout: 2015-12-11, and really hope that some solution can be found, soon. AllanR.
*** Bug 96660 has been marked as a duplicate of this bug. ***
Perhaps something along the lines of how Notepad++ treats this - when a document is modified the FD icon goes red. Once saved the icon returns to normal. AllanR
Don't know why this one is set to "Wontfix". The normal behavior in every program is to set only one function to the save button - no submenue. And the normal behavior is to grey this button out to show the user: The content of this document has been saved. Why isn't there a submenue set to the button "Save As", which would be never greyed out, because this function would make sense more than one time. OK, you could change this per expert config. For non-experts the normal way would be: Never install LO 5.1, because the non-expert wouldn't see any more if the content has been saved. Don't say: There is a little sign in the bottom of your Writer-window, which shows with a very little star: This document has been changed.
(In reply to robert from comment #9) > The normal behavior in every > program is to set only one function to the save button - no submenue. So what? If other programs don't have some features, does it mean we should never implement them? > And > the normal behavior is to grey this button out to show the user: The content > of this document has been saved. At least MS Office doesn't do this. > Why isn't there a submenue set to the button "Save As", which would be never > greyed out, because this function would make sense more than one time. Agree. That's the solution I prefer too, but it has been rejected by the design team. > OK, you could change this per expert config. Update on this: It seems that the current plan is to not retain the current expert config workaround I mentioned in my previous comment. Have no idea whether there will be a different workaround at some point. > Don't say: There is a little sign in the > bottom of your Writer-window, which shows with a very little star: This > document has been changed. Please re-read the design minutes I linked to. There will be a clear indication *on* the save button if the document is modified.
I must say that, even if I definitely do not want to be bickering, IMHO any effort or energy put into this transformation, given the dubious advantages it would (perhaps) offer, is far from efficient. There so many areas of our beloved LO that needs significant improvements, that would benefit hugely from some of this energy! I know this is not in the style of bug reporting, (one bug - one report etc.) but just for once allow me to mention some of the most blatant - and unattended - at once: - the whole management of tables in Impress is in high need of revision - problems of slowness, clunckyness in use, blatantly incorrect visualization of most the formatting options, and - alas - more. This is a functionality of LO (and OO before, I filed a bug report on this a coupe of years ago) that you'd rather not show to people not using LO, to avoid spreading negative impressions - the slow response of Draw and Impress interface in 5.1.0.1, which is frightening: if this is not polished away, it makes the two modules an headache to use! a program can have the greatest functionality, still that's useless if the most basic and commonplace functions are DEAD SLOW....see my bug 96658, so far not very considered it seems - the mysterious working of openCL, resulting in serious computational errors in CALC (see my bug 96222), a problem that seems difficult to grasp, looking at the suggestions received that were all quite off the mark Sorry...
Andy: Thanks for your reports, but because of the reasons you wrote yourself, they will be only ignored. If you really want to help sorting out the issues, please report them correctly - as new bugs, with exact steps how to reproduce. For example, "slow response of Draw and Impress interface" indeed sounds frightening, but without further/exact details how to see it (for a developer), nobody will do anything about that. Hope you understand - there are thousands of bugs, and nobody is going through closed ones just to check for unrelated reports.
Regarding "slow response of Draw and Impress interface", do you mean that the description I wrote in bug 96658 is not clear enough? And if so, what do you think should I do to make it clearer?
As a normal user just moved on to 5.0.1.2 I really don't like the change. I rely on the button and/or menu item being greyed out to tell me if the document has been saved or not. Please re-instate some form of clear visual indication that the document does or does not need saving.
(In reply to tim from comment #14) > Please re-instate some form of clear visual indication that the document > does or does not need saving. There will be in RC3.
(In reply to tim from comment #14) > As a normal user just moved on to 5.0.1.2 > ... I suppose you meant 5.1.0.2 a s a "normal user" you should keep using 5.0.4.2 for production the 5.1.0.2 is a "release candidate" of a development branch as clearly stated in the download page: http://www.libreoffice.org/download/pre-releases/ These are pre-release versions and are not recommended for production use. Interested in helping out? Please read the release notes and visit our Testers page. ----- so it's great if you download a pre-release and test it, but do not get upset if you find bugs that alter your workflow during production. moreover as Maxim said, a visual hint about saving will be featured in 5.1.0.3 RC you can already test a 5.1.x daily build here http://dev-builds.libreoffice.org/daily/ and tell if the change is satisfying
(In reply to tommy27 from comment #16) > (In reply to tim from comment #14) > > As a normal user just moved on to 5.0.1.2 > > ... > > I suppose you meant 5.1.0.2 > > a s a "normal user" you should keep using 5.0.4.2 for production > the 5.1.0.2 is a "release candidate" of a development branch > > as clearly stated in the download page: > http://www.libreoffice.org/download/pre-releases/ > > These are pre-release versions and are not recommended for production use. > Interested in helping out? Please read the release notes and visit our > Testers page. > > ----- > > so it's great if you download a pre-release and test it, but do not get > upset if you find bugs that alter your workflow during production. > > moreover as Maxim said, a visual hint about saving will be featured in > 5.1.0.3 RC > > you can already test a 5.1.x daily build here > http://dev-builds.libreoffice.org/daily/ > > and tell if the change is satisfying Yes - sorry - I meant 5.1.0.2. I wanted to try this release because of several bugs in to 5.0.4.2 that made it unusable for my purposes. I'm not a 'production ' user, but a home user for some databases, spreadsheets and so on. I don't mind being on a beta release, provide that when I make a comment it's received in the spirit intended. The WONTFIX status is a little misleading, since it seems 'SOMEFIX' will be made :-)
I've changed the Summary of the bug; this way we can mark it as FIXED :-) Maxim did all the hard work here - thanks for that! RC3 will have the indication of the status. It won't be 'greying out' though (as save will be available all the time), only a visual hint.
(In reply to Jan Holesovsky from comment #18) > I've changed the Summary of the bug; this way we can mark it as FIXED :-) > > Maxim did all the hard work here - thanks for that! RC3 will have the > indication of the status. It won't be 'greying out' though (as save will be > available all the time), only a visual hint. :-)
Just installed 5.1.0.3 (x86 on Win10 x64 Enterprise fully updated) and noted the annoying change in the save button function. The discussion here suggests that it will now show a "hint" of the save status of the document; so it does but the faint blue star is a poor replacement of the very clear status indicator which existed before. Could this be made rather more obvious? If there really must be this "always save" function here, might I suggest making the default icon (for a saved or unaltered document) grey and that the icon changes to the standard one if the document has changed?
This indication does need to be very clear. To cut a longish story short there are issues with Base (and maybe other modules) and Macros whereby if you do not manually save first, but close and wait until it asks if you want to save and then say 'save', it tends to crash quite frequently. Unfortunately I have been unable to create a reliable repeatable example of this, and it sometimes crashes even when I do manually save first (as in #96877). So please ensure that any indication that a save is required is really really clear. I don't really understand the reason for the change to Save (rather than Save As) , but I'm sure it makes sense to the design team.
I've just installed Version: 5.1.0.3 Build ID: 1:5.1.0~rc3-0ubuntu1~trusty0. The new 'not saved' indication is fine on my system - it shows very clearly. Thanks.
Sorry, but I must agree that a "faint blue star is a poor replacement of the very clear status indicator which existed before" . Hope it can be replaced with something more clear.
John, Andrej: We would very welcome your contribution to the project! The save icons are here: https://cgit.freedesktop.org/libreoffice/core/plain/icon-themes/galaxy/cmd/lc_save.png https://cgit.freedesktop.org/libreoffice/core/plain/icon-themes/galaxy/cmd/sc_save.png The current 'not saved' variants are here: https://cgit.freedesktop.org/libreoffice/core/plain/icon-themes/galaxy/res/savemodified_large.png https://cgit.freedesktop.org/libreoffice/core/plain/icon-themes/galaxy/res/savemodified_small.png Can you please propose better variants? Best to open a new bugreport though.
[Similarly you can get location of other icon themes, just change the 'galaxy' to eg. 'tango' etc. - to get the other themes. Full list of themes is here: https://cgit.freedesktop.org/libreoffice/core/tree/icon-themes Thank you in advance for your contributions!]
I'm on ubuntu 14.04, not using any theme for libreoffice, but possibly employing some ubuntu theme. So the Save button on my system is very different from the new 'Not Saved' icon, which is why I'm content. The background colour is different, so the addition of the star just adds even more to it. It's light grey with a green arrow when saved, and a dark brown floppy disc icon with star when not saved.
@tim please post a screenshot so we may better understand what you are describing
Created attachment 122610 [details] document has been saved This is a writer doc that has been saved.
Created attachment 122611 [details] This needs saving This one needs to be saved.
I just had a look at the attachment, the "blue star" is visible but not overwhelmingly so, I would try and make it stand out more... this is an indicator nobody stares into for a long time, rather something that should be easy to spot in a quick glance. I am not used to these (because I'm a windoze user or a user of a different icon set), but the 2 are clearly different (the difference between them is much more evident than the blue star), unfortunately they really suggest two different things: a hard disk the "saved" one and a floppy disk for the "needs saving" one. So I must say that I don't find them fitting, as their difference should convey a meaning that is different from their visual content. IMHO an icon is as good as is intuitive in visually conveying the concept it stands for. Alternatively, I would avoid differing icons and opt for a much more visible and "alarming" signal on the icon, such a bog red point (="ALARM!! this need to be saved!!!") as I placed in my attachment. This said, I must admit that the whole business of changing the standard behaviour of the save icon still appears somewhat a waste of energies more usefully spent of other more urgent issues to me. It is really the LAST thing I would have voted as neeeding urgent care... but opinions differ obviously so that's it.
Created attachment 122625 [details] More visible signal of the need to save
(In reply to tim from comment #26) > So the Save button on my system is very different from the new 'Not Saved' > icon, which is why I'm content. That's because you're using the Human icon theme, which doesn't have "not saved" icon, so it fallbacks to Tango theme for this particular icon. Any suggestions for a Human "not saved" icon are welcome.
(In reply to Maxim Monastirsky from comment #32) > (In reply to tim from comment #26) > > So the Save button on my system is very different from the new 'Not Saved' > > icon, which is why I'm content. > That's because you're using the Human icon theme, which doesn't have "not > saved" icon, so it fallbacks to Tango theme for this particular icon. Any > suggestions for a Human "not saved" icon are welcome. If you say so. I'm not aware of using any specific theme, and my libreoffice doesn't mention it at all. Never mind :)
No point in continuing discussion in a closed bug, opened a new one for the Human theme: bug 97866
*** Bug 97561 has been marked as a duplicate of this bug. ***
*** Bug 98649 has been marked as a duplicate of this bug. ***
Nobody seems to notice that this change affects those of us who use text buttons rather than icons. Using a different icon has no effect on a text button. Is this just another example of treating text as a second-class (or last-class) alternative? Doesn't anybody on the "design team" even try to use text and see if it actually works?
(In reply to Dave Close from comment #37) > Nobody seems to notice that this change affects those of us who use text > buttons rather than icons. Using a different icon has no effect on a text > button. Is this just another example of treating text as a second-class (or > last-class) alternative? Doesn't anybody on the "design team" even try to > use text and see if it actually works? As already written: no point in continuing discussion in a closed bug, please open a new one and add needsUXEval in keywords.
And probably no point to opening a different ticket, with or without a special tag. It seems clear to me that the developers don't care about text buttons. If anyone cared, the comments in this ticket should be enough to get them started, without the need for a user to open a ticket.