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:
> 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
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).
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.
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.
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.
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.
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.
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.
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.
This "feature" or bug is still present in LibreOffice 7.0.1.2 on Ubuntu 18.04 LTS; Fresh LO from PPA. Version: 7.0.1.2 Build ID: 00(Build:2) CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.0.1_rc2-0ubuntu0.18.04.1 Calc: threaded
I have also noticed this resurfacing in 7.0.1, but only with Impress (not Writer or Calc). 6.4.4.2 works correctly, closing the empty template file when I open a file. However, even in 6.4.4.2, Impress does not close the empty file any time I opened multiple files at once. Neither Writer nor Calc has that problem, either, so something is a little different about how Impress is working.
(In reply to bchemnet from comment #11) > I have also noticed this resurfacing in 7.0.1, but only with Impress (not > Writer or Calc). 6.4.4.2 works correctly, closing the empty template file > when I open a file. However, even in 6.4.4.2, Impress does not close the > empty file any time I opened multiple files at once. Neither Writer nor > Calc has that problem, either, so something is a little different about how > Impress is working. Impress is even broken with the default file and that is actually a regression from my patch. A pending fix is: https://gerrit.libreoffice.org/c/core/+/104581 This needs more review and testing. And if I open a default document, but then select a document of any other module, it'll also open in a new window. I also tested this in 5.2, so this seems to be the default behavior.
(In reply to Jan-Marek Glogowski from comment #12) > Impress is even broken with the default file and that is actually a > regression from my patch. A pending fix is: > https://gerrit.libreoffice.org/c/core/+/104581 > > This needs more review and testing. @bchemnet, andorjkiss: Would you be willing to do some testing whether this works as expected now in case we provide you with a test build that includes the fix?
(In reply to Michael Weghorn from comment #13) > @bchemnet, andorjkiss: Would you be willing to do some testing whether this > works as expected now in case we provide you with a test build that includes > the fix? Yes, I can test a build.
(In reply to bchemnet from comment #14) > Yes, I can test a build. Great, thanks. I've (temporarily) uploaded the test build here: https://nextcloud.documentfoundation.org/s/Tw7C5GHdP6cAAC7 (This is the current development version, master, as of commit 0c765dedffa2c0ee9e6daeb54d8d477b71a56e61 + the Gerrit patch on top). You can install that one in parallel as described at [1]. That build was done on Debian stable (buster), so presumably won't work on systems with much older libraries, but since you mentioned in your initial post that you were using the Debian build of 6.3.0.2 rc2, this should probably work. [1] https://wiki.documentfoundation.org/Installing_in_parallel/Linux
(In reply to Michael Weghorn from comment #15) > Great, thanks. I've (temporarily) uploaded the test build here: This version works as I expect, both with a fresh profile and my existing profile, which uses a custom template. All completely unedited new documents, regardless of template, are replaced whenever I open one or more files. Touched documents are not. So it appears to be behaving in the same way as Writer and Calc now.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d4892e5452bff155da6c34063ffe8c331284d8e9 tdf#126700 handle Impress default documents It will be available in 7.1.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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/432b72852fc3cd39392f6fd878e946790024a412 tdf#126700 handle Impress default documents It will be available in 7.0.4. 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.