https://bugs.documentfoundation.org/show_bug.cgi?id=101302
Mike Kaganski <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|bibisectNotNeeded, |difficultyInteresting, |regression |easyHack, skillCpp --- Comment #41 from Mike Kaganski <[email protected]> --- (In reply to Maxim Monastirsky from comment #8) > The only sane way of solving this is to do the check in > asynchronous way, i.e. check and add the files to the list in the > background, without blocking the UI. (In reply to Mike Kaganski from comment #32) > A proper fix would be drawing default *module* thumbnail on opening start > center (detected from document extension, or from last used filter, which is > available in the entries, i.e. without any actual file access); then > retrieve all necessary information (encrypted status, availability (bug > 101302), anything else) asynchronously in multiple threads, updating the > thumbnails as the data is available. > > Multiple threads are needed to avoid blocking other thumbnails when a single > document is unavailable. Having several threads would allow the thread > handling the unavailable document to wait, while other threads succeeding > independently. So here is the code pointer. Currently (after recent changes) thumbnail generation is performed fully in RecentDocsViewItem constructor [1]. It has two cases: where a pre-created thumbnail is present (see line 208), and when it's absent (line 167). The former one currently does not attempt to access files, only using pre-existing thumbnail and file name to draw the element in the start center; the latter tries to access the document trying to detect if the document is protected (at which case, it may be problematic when the file is unreachable - see e.g. bug 144566). The change should: 1. Change second case to not attempt to access files, drawing default thumbnail without lock to avoid UI blocking; 2. Introduce a thread (one for all, or per-item) to access files asynchronously, detecting (a) file availability, and (b) file encryption/password protection. This should result in unavailable items being re-drawn (either as dimmed, or maybe using some overlay indicating its unavailable status), and protected ones re-drawn with lock - when that data is available. The thread should update the item's maPreview1, and use some method of RecentDocsView [2] to update specific items (note that existing RecentDocsView::Reload is not suitable, since it re-creates all the items). It should be possible to terminate the thread early, when user leaves the recent list (e.g., opens a file or switches to templates view). I clean the unreasonable "regression" keyword (the statement that it should *not* show inaccessible files is nonsense, and the solution should only be marking elements slowly). Marking it as an interesting easy hack. [1] https://opengrok.libreoffice.org/xref/core/sfx2/source/control/recentdocsviewitem.cxx?r=1dbed50a#123 [2] https://opengrok.libreoffice.org/xref/core/sfx2/inc/recentdocsview.hxx?r=1dbed50a#60 -- You are receiving this mail because: You are the assignee for the bug.
