Download it now!
Bug 126700 - Untitled document remains open when have a default template
Summary: Untitled document remains open when have a default template
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Jan-Marek Glogowski
URL:
Whiteboard: target:7.0.0 target:6.4.2 target:6.3.6
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-04 19:49 UTC by bchemnet
Modified: 2020-02-15 13:02 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bchemnet 2019-08-04 19:49:02 UTC
Description:
This is in regard to https://bugs.documentfoundation.org/show_bug.cgi?id=83722, which made a substantial change to the behavior of LO.  The net result of this leaving the initial "untitled" window open when template information is present, even if absolutely no modifications have been made, is that I have a proliferation of "untitled" windows going on.

Steps to reproduce:
1. Set a default template (in Writer, Calc, whatever - I have it for all modules)
2. Start Libreoffice.
3. Immediately open an existing document.
4. Note that the "untitled" window is still open.

As I often have documents open on multiple desktop views, and often find it fastest to get a new window by "starting" LO even though it is running, this means I am constantly having to close untitled windows.

I realize I can change my workflow, but I do not see why I should have to.  The new behavior is inconsistent with the behavior of every document management program I have worked with for 30 years, and for no good reason.  I understand the motiviation - do not close the untitled doc if it is holding modified template information.  Fine.  But a better solution is needed, because ANY template information is triggering this.  Please rework or revert this change.

In the event it matters, I am currently running 6.3.0.2 rc2, Debian build.

Actual Results:
See description.

Expected Results:
See description.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Katarina Behrens (Inactive) 2019-08-05 07:30:23 UTC
> The new behavior is inconsistent with the behavior of every document
> management program I have worked with for 30 years, and for no good reason. 

It is consistent with the behaviour of MS Office which opens a new document in a new window if there is another document opened from template in the old window. 

This is where the request for bugfix came from: the users migrating from MS Office found it unacceptable that content provided by a template is silently replaced by a new document. 

I've no idea which document management systems you've worked with in last 30 years, but maybe MS Office wasn't one of them? 

Atm I have no constructive idea how can people have it both ways except for "introducing yet another compatibility configuration option and give those who think they shouldn't have to change their workflow a possibility to get the old behaviour back" which is not constructive at all
Comment 2 bchemnet 2019-08-05 10:42:05 UTC
In MS Office, if one *explicitly* opens a new document from a template, the document is flagged as modified and so not replaced if another document is opened.  That is not the case if the user has set a *default* template; then new documents are still replaced, because the user has taken no action to indicate "leave this window alone".

That is my problem here: all of my new document windows remain open only because I have a default template.  I am never taking any action to flag those windows as in-use.  So every time I start Libreoffice, even completely fresh, and then want to open a document, I get an unwanted "untitled" window.  That is the part that is inconsistent.  An automatically created new window (such as program start) that draws from a default template should not be flagged as in-use, and should be replaced.

To be clear: I never open a document as a template.  If I explicitly did that and then immediately opened something else, I can see the utility in the patch.  But simply keeping all untitled windows open if they have template information is going too far, and makes it more frustrating to work with a default template (which is one of the things that Libreoffice is far stronger in than MS office).
Comment 3 bchemnet 2019-08-11 23:38:16 UTC
In case it is unclear from previous comments, this is triggered when starting Libreoffice as "Writer" or "Calc", rather than through the Startcenter.  For me, the Startcenter is cumbersome and slows me down, so I have always avoided it.  With this bug, I now have a choice of either only opening Libreoffice via the Startcenter or having to constantly close "untitled" windows.  The Startcenter solution is obnoxious to me because if I am working in a desktop view that does not have any open Libreoffice windows, the fastest way to open a new file is to start a new window and then open my file.  This works if I open "Writer", etc.  But if I open Startcenter, I am refocused to my first opened window, which is not where I want to be in this circumstance, and so I still end up with additional clicks to reorder my windows.

I think the issue with relating this to the MS suite is that if I start an instance of Word or Excel, the resulting window is not flagged as used in anyway, even if an instance of Word or Excel is already running.  But in Libreoffice, because everything is literally part of the same program, it seems that starting "Writer" or "Calc" is identical to explicitly requesting a new file.  But those two things are in fact not the same in workflow, and so flagging all "untitled" windows with a template as "in use" is inappropriate.

Personally, I would like to see the change reverted, as it is a significant change in the way that Libreoffice has worked from the first time I used it 15 years ago.  Failing that, at least please modify it so that starting a new program instance is different from clicking "new file" in Startcenter or an existing instance.
Comment 4 Jan-Marek Glogowski 2020-02-05 19:11:48 UTC
I can confirm this behavior. For whatever reason, a changed default document template isn't handled as an empty document, e.g. configured via

  <item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.sheet.SpreadsheetDocument']">
    <prop oor:name="ooSetupFactorySystemDefaultTemplateChanged" oor:op="fuse">
     <value>true</value>
    </prop>
  </item>
  <item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.sheet.SpreadsheetDocument']">
    <prop oor:name="ooSetupFactoryTemplateFile" oor:op="fuse">
     <value>$(inst)/share/template/empty/soffice.ots</value>
    </prop>
  </item>

This factory default template still works correctly, so most people simply won't have noticed this change.
ooSetupFactoryTemplateFile is also the value in user/registrymodifications.xcu, if you use the "Set as Default" from the right click menu of templates in the template manager - kind of well hidden.

Looking into officecfg/registry/schema/org/openoffice/Setup.xcs, I actually found three settings, which might be related to the default template handling:
 * ooSetupFactoryTemplateFile
 * ooSetupFactorySystemDefaultTemplateChanged
 * ooSetupFactoryEmptyDocumentURL

The difference is between a "manually" opened template and the automatically "empty" template of the LO module. IMHO the later one should still be replaced by any user opened document, if it hasn't been modified.
Comment 5 Jan-Marek Glogowski 2020-02-11 11:35:20 UTC
There is now: https://gerrit.libreoffice.org/c/core/+/88257

Originally I tried to find some other indicator in the current API, but failed. So this adds a new "flag" to the MediaDescriptor, which allows the API to mark a document as Replaceable and automatically set this flag for the default "empty" documents of the LO modules.
Comment 6 Commit Notification 2020-02-11 23:28:52 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/61e1e0413296928d929f99c0f006c6cbbcf4ac40

tdf#126700 allow replacing the default documents

It will be available in 7.0.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 7 Commit Notification 2020-02-13 09:20:04 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

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

tdf#126700 allow replacing the default documents

It will be available in 6.4.2.

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 8 Commit Notification 2020-02-14 14:30:12 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

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

tdf#126700 allow replacing the default documents

It will be available in 6.3.6.

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 9 bchemnet 2020-02-15 13:02:34 UTC
Thank you, Jan-Marek.  I can confirm that this issue is resolved in the current nightly build.  The new behavior is consistent with all versions prior to 6.3 in all the test cases that I ran.