Steps to reproduce: 1. Use File->Open to open a PDF *using Writer's PDF filter*. 2. Close all open documents, and open Start Center. 3. Click on the thumbnail of the PDF. => it opens in Draw (the default module handling PDFs). It would be better to use the filter used last time (and thus open in Writer). Code pointers: The population of recent items happens in RecentDocsView::Reload (sfx2/source/control/recentdocsview.cxx). The last used filter is available from the registrymodifications.xcu along with URL and thumbnail data, and could be used when inserting items. Then RecentDocsViewItem::OpenDocument (sfx2/source/control/recentdocsviewitem.cxx) could use that information.
Using the last used filter name, thus bypassing the type detection might not be a good idea (like mentioned in the commit message of https://cgit.freedesktop.org/libreoffice/core/commit/?id=c238c19d2fed00919e02c4bc268d99ceaa73aca1). An alternative approach might be to store the last used app id, and let the type detection decide which filter to use based on that, in case the detected type is indeed can be handled by several apps. This what I suggested in Bug 65017 comment 20.
(In reply to Maxim Monastirsky from comment #1) > Using the last used filter name, thus bypassing the type detection might not > be a good idea (like mentioned in the commit message of > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=c238c19d2fed00919e02c4bc268d99ceaa73aca1). Unfortunately the commit message does not describe why it might be bad. > An alternative approach might > be to store the last used app id, and let the type detection decide which > filter to use based on that, in case the detected type is indeed can be > handled by several apps. This what I suggested in Bug 65017 comment 20. Personally I'd prefer thumbnails to have own context menus for cases when last filter (not module! filter is more specific, so I don't think storing module is adequate substitution) should be changed, having (among others like "remove" or imaginary "lock in the list") the menu items like "open using last filter" (the default), "open in module foo", and "open using default filter". An example where storing module would not be adequate is explicitly opening an FODT as plain text (also in Writer).
(In reply to Mike Kaganski from comment #2) > Unfortunately the commit message does not describe why it might be bad. Don't remember all the details, but what comes to my mind now is that some type detectors do preparation work which otherwise not done by the filter. See how Bug 90225 is implemented, for example. Another affected case might be clicking on an encrypted docx file, then cancelling the password prompt. The type detection code has a way to handle this situation (see Bug 80999), but I believe the filter will just throw a "general error" message. At least we need to identify all those corner cases, and fix them. (It might also happen that the underlying format of a file was changed, or that we changed the filter name during the course of development (e.g. when switching to external libs like liborcus or librevenge), but those scenarios are not common.) > An example where storing module would not be adequate is explicitly opening > an FODT as plain text (also in Writer). Is this actually possible from UI? I can't find a way to do this, at least under Linux.
(In reply to Maxim Monastirsky from comment #3) > Don't remember all the details, but what comes to my mind now is that some > type detectors do preparation work which otherwise not done by the filter. > See how Bug 90225 is implemented, for example. Another affected case might > be clicking on an encrypted docx file, then cancelling the password prompt. > The type detection code has a way to handle this situation (see Bug 80999), > but I believe the filter will just throw a "general error" message. At least > we need to identify all those corner cases, and fix them. Yes they all are of course bugs - see e.g. tdf#129096 which obviously had to workaround this problem. > > An example where storing module would not be adequate is explicitly opening > > an FODT as plain text (also in Writer). > Is this actually possible from UI? I can't find a way to do this, at least > under Linux. Of course: you explicitly select "Text (.txt)" as filter in the File Open dialog (some native dialogs might make it mode difficult than others, but that is not LibreOffice limitation, but a specific dialog implementation detail; e.g. on Windows, clicking on the FODT first to have the name in Name box, then selecting the filter keeps the name in the Name box, and then OK does the expected thing).
Switching the module sounds like a bad plan. And File > Open... (PDF) always loads the document into Draw, doesn't it?
(In reply to Heiko Tietze from comment #5) > Switching the module sounds like a bad plan. Sorry, what is "Switching the module"? > And File > Open... (PDF) always loads the document into Draw, doesn't it? I fail to see the relation of this incorrect statement to this problem (incorrect, because when you use File->Open, you are free to choose Writer's PDF filter to load it into Writer).
(In reply to Mike Kaganski from comment #6) > Sorry, what is "Switching the module"? PDF's are usually opened in Draw and if you switch to Writer it might confuse users. Of course, the related question is how File > Open (PDF) works. > > And File > Open... (PDF) always loads the document into Draw, doesn't it? > > ... you are free to choose Writer's PDF filter to load it into Writer). How exactly?
Created attachment 159446 [details] Screencast: Open PDF in Writer (In reply to Heiko Tietze from comment #7) > (In reply to Mike Kaganski from comment #6) > > Sorry, what is "Switching the module"? > > PDF's are usually opened in Draw and if you switch to Writer it might > confuse users. Of course, the related question is how File > Open (PDF) > works. I'm sorry, I don't understand what you might mean writing "if you switch to Writer it might confuse users". Who is "you" and who is "users" in that sentence? Just in case, this issue is about *user* explicitly opened some file using some specific filter (PDF is an example; it might be a CSV having TXT extension, which is quite common), and so has that element in own recent list; then when *that same user* opens *that same file* from the recent list, the file is open using a *different* filter. > > > And File > Open... (PDF) always loads the document into Draw, doesn't it? > > > > ... you are free to choose Writer's PDF filter to load it into Writer). > > How exactly? See attachment.
Created attachment 159447 [details] Screencast: a TXT opened as CSV is later opened as plain text in Writer The screencast should clarify what this issue is about. Initially I explicitly used CSV filter to open a file having TXT extension; then I closed the spreadsheet, and re-opened it from recent list in start center, to show that it was opened as plain text in Writer - not the way I want. My expectation would be that it opened the same way it was opened last time, as CSV in Calc. The information is kept in registrymodifications, it's just not used. (And by the way, it's not used also when choosing the icon shown in the recent list, which is sad.)
(In reply to Mike Kaganski from comment #8) > Created attachment 159446 [details] Okay, got what you mean with filter (thought it was the module). Usually the file filter affects the list of documents in the file browser and not the application. I mean if you open a bmp or png in GIMP you always get the picture in the same application. And I expected Open without changes to the filter to work in the same way as when the list is filtered - both open in Draw. I remember the discussions where to open CSVs. But still not the usual workflow when you decide by filtering the list of documents where it's opened. So my take is to simplify it and always open in the designated module. To load PDFs or CSVs into Writer we should use a special command.
No further input, removing UX. I believe storing the filter is a corner case and not worth the effort. If we really want to allow other than the default module we could add this to a content menu, which would be nice to have anyway.
(In reply to Mike Kaganski from comment #2) > > Personally I'd prefer thumbnails to have own context menus for cases when > last filter (not module! filter is more specific, so I don't think storing > module is adequate substitution) should be changed, having (among others > like "remove" or imaginary "lock in the list") the menu items like "open > using last filter" (the default), "open in module foo", and "open using > default filter". > I like this idea. Rather than remembering the last used filter per MRU entry, adding a context menu selector for filter/module to use would be helpful. If you get the wrong filter/module from the default--just close and reopen with a filter selection from the SC's MRU thumbnail.
My related bug 151553 is about the same issue, but - in the File | Recent menu. I was thinking of marking it as a dupe, but - it can't be a dupe considering the solution some have suggested here, which is a context menu; since we can't have context menus for other menu entries... Anyway, for the start center as well - my preference would be for a file to be opened using the same filter it was last opened with. And perhaps - when hovering over the module icon, the text would show the full input filter name rather than the filename.