Till 3.3.2, LibO opened my "Mes modèles" folder containing my own templates when selecting "File > New > Template". In 3.4rc1, it keeps leaving this folder and displaying its parent folder. This is a regression as it forces me to reopen my "Mes modèles" folder again and again. It should remember where I use to look for my templates, as it did in older releases.
(In reply to comment #0) In my company, we prefer to have this new behavior of restoring the template parent folder, because we have some template folders and is important to us to open the templates on the parent default folder. So, I suggest that this issue should be an option in LO preferences rather than return to the previous functionality.
*** Bug 38009 has been marked as a duplicate of this bug. ***
This problem still exists in 3.4.3. The description in Bug 38009 is more complete. If it is decided to make this an option to either open the last folder or open the parent folder, then it should just do one or the other. Currently it opens the last folder, then delays a bit, then switches to the parent folder. During the delay, you cannot select a template in the last folder even though you can see templates listed.
Devs, is there any progress on this bug? I can confirm it is still present in 3.4.3-4 (Arch Linux). I don't know how much trouble this one is to fix, but I can relate that it is one of the top frustrations in Libre Office right now. For users like myself that have multiple templates for letterhead, etc., having to watch my templates disappear right in front of my eyes when LO magically jumps from the 'My Templates' directory (last used) up to the parent folder under File -> New -> Templates and Documents is frustrating. This happens with every letter I have to write. I know manpower is always stretched, but if this one could be bumped up a bit in priority, it would get rid of one of the most visible bugs introduced in 3.4 (or late 3.3). It doesn't seem that difficult to just tell LO to stay with the 'last used' template directory. It has done that for years before this got introduced. From a rational standpoint, I don't know of anyone that uses any of the canned templates provided in LO (or any other office suite for that matter). The only templates a majority of users ever use are those they have created which get stored under 'Templates and Documents' -> 'My Templates' in LO. That, in my experience, has always been where OO/LO returned to when the user selects File -> New -> Templates and Documents prior to this bug. Thanks for any help you can give to this bug -- it's one I'm reminded of every single day.
Just to be clear though, the problem can easily be demonstrated using just the few templates provided with the standard install. This is not an issue with custom folders. For example, start a presentation using one of the templates in the Presentation Backgrounds folder. Then try to make another new document from any template. The Presentation Backgrounds folder will initially be open, but the templates in it will not be selectable. After a few moments of inactivity, the dialog will jump up to the parent folder.
Please don't change the LibO version, see → http://wiki.documentfoundation.org/BugReport_Details#Version
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
thanks for posting this issue - didn't put energy in it myself, but each time starting from a template takes about four additional key strokes ..
Hi Joseph, Sorry my C++ is not so good. Therefore could you pls have a look at this commit: http://cgit.freedesktop.org/libreoffice/core/commit/?id=580ef36b0395c01eadc4e1cd5db506821f761c33 It could be related to this bug? Thanks! - Cor
The relevant code looks overly complicated. Removing *two* entries off the end of pHistoryList in SvtTemplateWindow::OpenHistory (svtools/source/contnr/templwin.cxx) indeed looks odd, but is effectively in there "since the beginning" (subsequent commits just changed the underlying data structures). What apparently happens if you follow the steps described in bug 38009 and you reopen the dialog after you had selected a template from "My Templates" the last time it had been opened, is - a call to SvtTemplateWindow::AppendHistoryURL with the .../templates/en-US URL - followed by a call to SvtTemplateWindow::AppendHistoryURL with the .../templates/en-US/My%20Templates URL - followed by a call to ClearHistory -- this apparently comes from UpdateHdl_Impl, no idea what it is supposed to do - followed by another call to SvtTemplateWindow::AppendHistoryURL with the .../templates/en-US URL and in particular no calls to OpenHistory involved (which might therefore be a red herring after all) That code apparently needs further investigation...
@stephan: thanks for looking in this. I was so naive to think that the commit in that area ... but indeed, might be some underlying problem. Would it be of some / little help maybe if I find out what happens with writing data to /reading from the user config files, both in 3.3 and 3.4 version?
*** Bug 46194 has been marked as a duplicate of this bug. ***
just to confirm, still present in LO3.5
some testing makes clear that the value of the last open template folder is correctly written to the registrymodification.xcu: <item oor:path="/org.openoffice.Office.Views/Dialogs"><node oor:name="NewFromTemplate" oor:op="replace"><node oor:name="UserData"><prop oor:name="LastFolder" oor:op="fuse" oor:type="xs:string"> also it is read from that file, when initiating the dialog one can also see, that when the dialog is open, for a short time the last open folder is active ... but that state is reverted. Now only find where and why :-)
Cor, sorry for not responding to your earlier comment 11. As I said in comment 10, the code looks strange (but old and mostly unmodified), the flicker from right dir to wrong one apparently happens due to timer-triggered UpdateHdl_Impl. Am planning on looking some more into this (already refactored the code lightly).
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=32a5ad89a505be22fb8ca0b990a8991a7de6453a fdo#37593 Make sure needsUpdate compares canonicalized paths
Turns out jumping from the last opened directory to the template root directory shortly after opening the dialog is "by design," but should only happen in those (rare) cases where there were interim changes to the template set, invalidating the cached data. However, comparing the current state of the template set with the cached data in user/store/.templdir.cache did not take non-canonical pathnames (containing ".." segments) into account, so always considered there were changes, always updated the cache, and so always jumped back to the template root directory shortly after opening the dialog. Intending the fix to be included in libreoffice-3-5 (towards LO 3.5.2), too.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ec752de623f4f7c7e297422730f193034e21f93f&g=libreoffice-3-5 fdo#37593 Make sure needsUpdate compares canonicalized paths It will be available in LibreOffice 3.5.2.
*** Bug 47504 has been marked as a duplicate of this bug. ***
Verified (on WinXP 32b) with LOdev 3.5.2rc0+ Build ID: ec752de-73cb0b8-f269e46 [libreoffice-3-5~2012-03-19_11.08.23_LibO-Dev_3.5.2rc0...] OK, thanks. :)
*** Bug 47651 has been marked as a duplicate of this bug. ***
works fine again in daily build. Thanks Stephan!
I added Fix submitter as assignee because this will ease queries and bug tracking.