Bug 105985 - Make Template Manager's directory scanning smarter
Summary: Make Template Manager's directory scanning smarter
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval, perf
Depends on:
Blocks: Template-Manager
  Show dependency treegraph
 
Reported: 2017-02-13 15:13 UTC by Harald Koester
Modified: 2022-01-04 09:45 UTC (History)
5 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 Harald Koester 2017-02-13 15:13:47 UTC
Description:
See "Steps to Reproduce".

Steps to Reproduce:
[1] Open the “Paths” options dialogue: Tools > Options… > LibreOffice > Paths
[2] Add a folder to the Templates paths. The folder should contain a lot of files, I used the “Program” folder of Windows. 
[3] Close Options dialogue with OK.
[4] Start Template Manager: File > New > Templates. It looks like that LibreOffice hangs. After some minutes I cancelled LibreOffice without the possibility to save data.

Actual Results:  
I suppose, in this case LibreOffice scans the whole folder for templates. I don't know how long it will take in this case to scan the whole Program folder. 

Expected Results:
There are several possibilities to solve this problem:
(a) At least the user should be informed that LibreOffice is scanning specific folders for templates.
(b) Also at least cancelling the scan process should be possible.
(c) It may be reasonable to do not scan sub-folders.
(d) Possibly only folders which do not contain sub-folders could be selected in the options dialogue.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:51.0) Gecko/20100101 Firefox/51.0
Comment 1 Buovjaga 2017-02-19 18:12:51 UTC
I'll just go wild and set this to NEW without testing. It is true that your suggestions should be considered.
Comment 2 Xisco Faulí 2017-06-16 09:23:00 UTC
IMHO, this can be considered a duplicate of bug 101467

*** This bug has been marked as a duplicate of bug 101467 ***
Comment 3 Harald Koester 2017-12-04 14:04:05 UTC
I checked this bug again with version 5.3.7 and 5.4.3. The bug still exists in both versions. This means either the fix of bug 101467 does not work or this is another problem. Hence I set back this bug to unconfirmed, because it has not been independently tested.

I think the probability of occurence is not very high, but if it occurs there is the danger of data loss because the user has to cancel LibreOffice after a while without saving.
Comment 4 Buovjaga 2017-12-16 15:13:41 UTC
Bug 101467 was about memory leaks, while Harald's suggestions are worthwhile to consider on their own. Setting back to NEW
Comment 5 QA Administrators 2018-12-17 03:41:37 UTC Comment hidden (obsolete)
Comment 6 Harald Koester 2019-01-04 17:33:42 UTC
Bug still exists in version 6.1.4 (64 bit, Win10).
Comment 7 Harald Koester 2020-12-02 12:24:11 UTC
Bug still exists in version 7.0.3 (64 bit, Win 10).
Comment 8 Buovjaga 2021-12-22 14:03:06 UTC
(In reply to Harald Koester from comment #0)
> There are several possibilities to solve this problem:
> (a) At least the user should be informed that LibreOffice is scanning
> specific folders for templates.
> (b) Also at least cancelling the scan process should be possible.
> (c) It may be reasonable to do not scan sub-folders.
> (d) Possibly only folders which do not contain sub-folders could be selected
> in the options dialogue.

Let's actually ask the UX design team what they think of these ideas.
Comment 9 sdc.blanco 2021-12-22 14:12:41 UTC
If changes are made, then would be appropriate to update the note about what subfolders are inspected in this help file:

https://help.libreoffice.org/7.4/en-US/text/shared/guide/manage_templates.html
Comment 10 Heiko Tietze 2022-01-04 09:45:24 UTC
(In reply to Buovjaga from comment #8)
> Let's actually ask the UX design team what they think of these ideas.

The implementation has been improved recently for bug 131850 by removing the encryption check. 

Yet there are still some more or less corner cases left: files on a slow network storage, access via slow connections, unexpected number of files etc. The correct solution is to separate the loading of files (actually thumbnails) from the interaction, which requires to be done in an extra thread. And not knowing what files exists on the target must not block the interaction too. 

Could be an interesting GSoC project.


Reading templates from the program directory makes not much sense.