Bug 143578 - Add option - variable - not to ask to save document if changed
Summary: Add option - variable - not to ask to save document if changed
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low enhancement
Assignee: Heiko Tietze
URL:
Whiteboard: target:7.4.0
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-28 09:47 UTC by Timur
Modified: 2022-04-27 07:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2021-07-28 09:47:43 UTC
I ask for the option  not to ask to save document if changed.
2 reasons for this:
- very useful and time-saving in LO QA
- some folks would also like it, like in URL I posted.
Comment 1 Roman Kuznetsov 2021-07-28 10:00:13 UTC
Dislike from me
Comment 2 Mike Kaganski 2021-07-28 10:18:30 UTC
An editor is an application for creating/editing documents. The primary task is to keep the results of the edits. Everything else is not a primary task, and is dangerous - and especially with our ~unreliable user profile which we routinely ask to reset. It would safe some minor annoyance to a few, but even a single case of additional loss of work caused by this "feature" would outweigh all its benefit.

-1 from me.
Comment 3 Timur 2021-07-28 10:54:55 UTC
I rarely write that some feature is important for QA, and even if I do, an explanation that majority won't use it. Regardless, some will, others will never notice. I don't think that profile is so unreliable that it will turn off option save by itself. 

As for others, today I stumbled upon these:
https://ask.libreoffice.org/en/question/165931/how-to-stop-the-save-document-nag-when-exiting-writer/
https://www.reddit.com/r/libreoffice/comments/okpidf/any_way_to_disable_all_warnings/
Comment 4 Mike Kaganski 2021-07-28 11:43:09 UTC
(In reply to Timur from comment #3)
> I rarely write that some feature is important for QA, and even if I do, an
> explanation that majority won't use it. ...

I may be wrong, and please excuse me it I put something into your mouth that you didn't tell (note that many of us - me included - are not native English speakers :D) - but I suppose that you try to defend *yourself*. Please don't: we all do an important work here; and we all may have ideas that others don't like. I don't like this idea, and I tried to explain my reasons; that doesn't mean that my disagreement has something to do with trying to tell that you did something wrong (like "how dare you try to suggest something useful to QA!!!111111") - of course, I make conclusions from your words, like "for QA plus just a few questions means not a significant user base for a feature" - but again, let us concentrate on the essence of each one's reasons, and not start feel attacked, knowing that we discuss ideas, not persons :D even if we disagree. (I still do ;D)
Comment 5 Heiko Tietze 2021-08-09 13:51:21 UTC
Don't think we should not make compromises when it comes to safety. Imagine the user who accidentally switches saving reminder off loosing all the day-work. And for the QA work it's just one click.
Comment 6 Timur 2021-08-09 14:21:11 UTC
(In reply to Heiko Tietze from comment #5)
> Imagine the user who accidentally switches saving reminder off loosing all the
> day-work. 
Users are not idiots. Many "accidental switch" actions would change the behavior, you know you don't click or you learn it later (like with not printing of images etc.).

> And for the QA work it's just one click.
Really? It's 15 clicks in s single bibisect. Times 100 bibisects. Please count clicks and lost hair.

This went wrong with "idiot user" argument so I'll narrow down to having it just in Expert configuration. So with this change I set Unconfirmed once more.
Comment 7 csongor 2021-08-10 16:02:50 UTC
I also think this change would be a very dangerous modification. 

Just imagine what would happen if a user turns this feature on by accident. Opens dozens of files, makes changes here and there, sometimes uses Undo and finally closes them without worrying. 

They would say: LO didn't ask for saving so I must have reverted all of my changes.  

The time when they realise that they overwrote dozens of documents, can happen weeks or months later. It would cause huge anger, not without any reason. 

I think if you use Ctrl+S instead of clicking the icon, you would save a lot of time. 

Another solution is to create a macro for yourself. Assign Ctrl+Q to your SaveAndThenCloseTheDocument macro and you are done: Ctrl+Q saves and closes. You just need to use this every time, rather than exiting a different way.
Comment 8 Xisco Faulí 2021-08-10 16:05:06 UTC
(In reply to Heiko Tietze from comment #5)
> Don't think we should not make compromises when it comes to safety. Imagine
> the user who accidentally switches saving reminder off loosing all the
> day-work. And for the QA work it's just one click.

+1 from me.

@Timur, you can also use Ctrl+C in commandline on every step when bisecting
Comment 9 Xisco Faulí 2021-08-10 18:15:24 UTC
Besides, this enhancement was proposed with the idea in mind that it might help people doing QA, however, it might turned to be the opposite, having reports from users saying LibreOffice didn't warn them to save the document when closing it.
Comment 10 jan d 2021-08-10 19:07:33 UTC
Agree with people who oppose the suggestion. However, I understand the need that led to suggesting the feature.  

Maybe there are alternatives to the "expert option" e.g. a command line option, a testing harnish or script?
Comment 11 Heiko Tietze 2021-08-11 08:01:29 UTC
We have a couple of environment variables that could be enhanced.

DISPLAY - X11 display to use.
OOO_DISABLE_RECOVERY - Disables the recovery dialog.
OOO_EXIT_POST_STARTUP - Exit right after startup, for profiling purposes.
SAL_DISABLE_USERMIGRATION - Disable automatic conversion of old user configurations.
SAL_USE_VCLPLUGIN - Which VCL plugin to use instead of the auto-detected one.

Ultimately a QA topic that *must not* affect UX.
Comment 12 Timur 2021-08-11 08:36:44 UTC
(In reply to csongor from comment #7)
> I also think this change would be a very dangerous modification. 
> Just imagine what would happen if a user turns this feature on by accident.

(In reply to Xisco Faulí from comment #8)
> +1 from me.

I modified request from Comment 6 to have this is Expert configuration only. 
No way that (idiot or not) user may turn it on by accident.
Please comment on that.

Not sure if not-saving can be done from command-line option as in Comment 10.

> @Timur, you can also use Ctrl+C in commandline on every step when bisecting
You mean to close LO, good idea, thanks. 

@Heiko: 
please clarify, you set New, do you mean that original request and all from Comment 11 could be in Expert configuration?
Comment 13 Heiko Tietze 2021-08-12 08:59:45 UTC Comment hidden (obsolete)
Comment 14 Mike Kaganski 2021-08-12 09:18:58 UTC
(In reply to Heiko Tietze from comment #13)
> Another idea: How about a checkbox "[ ] Apply to all" that allows to either
> save documents in all modules or not depending on whether you press Save or
> Don't Save?

I disagree with this checkbox idea - a checkbox bears an idea of saving chosen state. But this could be just a second pair of buttons there in the dialog - like [ Save ] [ Don't save ] [ Save All ] [ Don't save all ] - implying that the action applies to all currently opened documents, but is just a one-time action.

But anyway, I believe this doesn't address this specific issue - this has never stated that the problem was about too many open documents, each needing own click. "15 clicks for a single bibisect" inplies ~1 click per bibisect iteration -> 1 modified file at a time, so the problem would not be mitigated by an option to apply an action to all currently opened documents.
Comment 15 Justin L 2021-08-12 15:28:54 UTC
I like the expert config idea because:
-it is almost impossible for a user to set by mistake.
-it can be managed with a setting extension.

I have a setting extension that I add to all of my bibisects. It is easier than trying to remember everything, and thus I have no qualms in deleting a user profile during testing - I only have to remember to add my extension (and Tip-Of-The-Days quickly reminds me if I forgot :-()

https://wiki.documentfoundation.org/Development/Extension_Development
Comment 16 Mike Kaganski 2022-02-15 07:45:56 UTC
(In reply to Justin L from comment #15)
> I like the expert config idea because:
> -it is almost impossible for a user to set by mistake.

Oh no!
It *is* possible to set "by mistake" - if not user's, then program's (note my mention of "our ~unreliable user profile" in comment 1). We are full of questions here and there telling about options that are only accessible from expert configuration, which have non-default values for people who likely never even touched that button (well, we can't know for sure, but ...).

If at all, please implement the environment variable solution.
Comment 17 Heiko Tietze 2022-02-15 08:10:27 UTC
(In reply to Mike Kaganski from comment #16)
> If at all, please implement the environment variable solution.

https://gerrit.libreoffice.org/c/core/+/129953

We could show an infobar. Not sure whether this hinders QA nor how (alleged) experts deal with this switch (likewise the query dialog you can block the infobar).
Comment 18 Mike Kaganski 2022-02-15 08:15:02 UTC Comment hidden (off-topic)
Comment 19 Heiko Tietze 2022-02-15 08:16:36 UTC Comment hidden (off-topic)
Comment 20 Xisco Faulí 2022-02-15 09:32:28 UTC
(In reply to Mike Kaganski from comment #16)
> (In reply to Justin L from comment #15)
> > I like the expert config idea because:
> > -it is almost impossible for a user to set by mistake.
> 
> Oh no!
> It *is* possible to set "by mistake" - if not user's, then program's (note
> my mention of "our ~unreliable user profile" in comment 1). We are full of
> questions here and there telling about options that are only accessible from
> expert configuration, which have non-default values for people who likely
> never even touched that button (well, we can't know for sure, but ...).
> 
> If at all, please implement the environment variable solution.

+1
Comment 21 Commit Notification 2022-02-16 11:16:34 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e7af16b2a6d097448a292cf19f04edcda82adf3a

Resolves tdf#143578 - Environment variable SAL_NO_QUERYSAVE to not show the dialog on changes

It will be available in 7.4.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.
Comment 22 Heiko Tietze 2022-02-16 11:17:08 UTC
The patch allows to start LibreOffice with the environment variable SAL_NO_QUERYSAVE. Any parameter works "true", "false", "1", and even "". So 'SAL_NO_QUERYSAVE="" soffice' will not show the query dialog.
Comment 23 Commit Notification 2022-02-16 12:29:57 UTC Comment hidden (obsolete)
Comment 24 Heiko Tietze 2022-02-16 12:30:10 UTC Comment hidden (obsolete)
Comment 25 Commit Notification 2022-02-18 07:08:57 UTC Comment hidden (obsolete)
Comment 26 Heiko Tietze 2022-02-18 07:10:01 UTC Comment hidden (obsolete)
Comment 27 Timur 2022-02-18 07:56:39 UTC
Thanks Heiko.
Comment 28 Timur 2022-02-18 11:36:29 UTC
It's already documentated at https://wiki.documentfoundation.org/Development/Environment_variables

But I'd rather put it in Desktop General table, with other explained variables, then in undocumented Other. 

Xisco, please ask ESC to all add description where known.
Comment 29 Xisco Faulí 2022-02-18 14:08:30 UTC
(In reply to Timur from comment #28)
> It's already documentated at
> https://wiki.documentfoundation.org/Development/Environment_variables
> 
> But I'd rather put it in Desktop General table, with other explained
> variables, then in undocumented Other. 
> 
> Xisco, please ask ESC to all add description where known.

Hossein is taking care of it
Comment 30 Timur 2022-03-09 09:56:46 UTC Comment hidden (obsolete)
Comment 31 Mike Kaganski 2022-03-09 10:34:58 UTC Comment hidden (obsolete)
Comment 32 Xisco Faulí 2022-03-09 11:18:14 UTC
(In reply to Mike Kaganski from comment #31)
> (In reply to Timur from comment #30)
> > Heiko, can you please backport it to 7.3?
> > No danger here, while bibisects have a long time to go.
> 
> No reason: the bibisect repo for 7.3 is finished (to the point of
> branch-off). Having it in 7.3.2 and later would not help bibisecting things
> appeared when 7.3 was master.

+1
Comment 33 Timur 2022-04-26 11:34:04 UTC
This works for closing document, but not for Reload. Please fix.
Comment 34 Heiko Tietze 2022-04-26 13:55:12 UTC
(In reply to Timur from comment #33)
> This works for closing document, but not for Reload. Please fix.

Please write a new ticket.