rodlie/qtfm

mimeapps.list repeatedly overwritten and not all apps listed to be added

Opened this issue · 3 comments

anilsg commented

Apologies if this is some basic error or lack of information on my part; I have been reading SO and open desktop specs and have tried many combinations and can't figure out what I'm doing wrong. If I am doing something wrong I've not been able to find documentation to correct me.

qtfm overwrites my ~/.config/mimeapps.list (or ~/.local/share/applications/mimeapps.list if I use that location).

  • Every time I attempted to make a change I made sure qtfm was not running while I edited any files
  • I confirmed that qtfm preferences were set to read the right mimeapps.list location
  • I removed all mimeapps.cache files that I found
  • I removed all defaults.list files that I could find

And still I got the following behaviour:

  1. Ensure ~/.config/mimeapps.list has mupdf.desktop as the first entry for application/pdf mimetype
  2. Start qtfm and open a PDF file - Master PDF editor is used instead
  3. Exit qtfm and find mimeapps.list has changed to remove mupdf.desktop entry

Expected behaviour:

  1. Ensure ~/.config/mimeapps.list has mupdf.desktop as the first entry for application/pdf mimetype
  2. Start qtfm and open a PDF file - MuPDF application is used
  3. Exit qtfm and find mimeapps.list has not changed

To be clear, the sequence is shown in bash here:

$ grep mupdf ~/.config/mimeapps.list

$ vim ~/.config/mimeapps.list

$ grep mupdf ~/.config/mimeapps.list
application/pdf=mupdf.desktop;masterpdfeditor4.desktop;chromium.desktop;gimp.desktop

$ sudo update-desktop-database

$ xdg-mime query default application/pdf
mupdf.desktop

$ qtfm

$ grep mupdf ~/.config/mimeapps.list

$ xdg-mime query default application/pdf
masterpdfeditor4.desktop

It appears that QtFM overwrites the mimeapps file on start up, but it's not clear where it takes the default file or entries that it uses to overwrite this file. Apologies if I misunderstand basic desktop usage but it was my expectation that applications should not write to this file (unless requested as part of user configuration).

If I try to use QtFM as the means to update my defaults, by using Edit > Settings > Mime Types, QtFM apparently only draws on that file for candidate applications, and it only does so after it has over-written the file. It does not refer to /usr/share/applications/, so the user can only change the order of the applications already in use for that particular mime type (within the over-written file, not as originally found in the file by QtFM on start up). Although mupdf.desktop is available in /usr/share/applications, since mupdf.desktop has been removed by QtFM from the mimeapps file, MuPDF is no longer available for use in QtFM Mime Type settings.

It does appear that QtFM over-writes the configured mimeapps.list file on start up. QtFM specifically over-writes the file that it is configured to read, to learn what the user defaults are, as set in Edit > Settings > Mime Types > Default mime applications Configuration file. It's not clear (to me) where QtFM gets it's authoritative mimeapps.list file from, as I have no other mimeapps.list or defaults.list files (that I can find) on my system.

$ ag -u -g mimeapps /
~/.config/mimeapps.list

$ ag -u -g defaults.list /

Could you please either clarify what I'm doing wrong here, or else fix QtFM to respect the standard properly?

If I'm doing something wrong, could you please clarify the correct usage in the man page or as appropriate?

Thanks

anilsg commented

Aargh - I did actually close this as a duplicate of #69 but I detect a difference.
My mupdf.desktop file does not include the Hidden=True flag, it only has NoDisplay
(and note I also added some Categories in order to try to help QtFM find it:

$ cat /usr/share/applications/mupdf.desktop
[Desktop Entry]
Name=MuPDF
GenericName=PDF file viewer
Exec=mupdf %f
TryExec=mupdf
Icon=mupdf
Terminal=false
Type=Application
MimeType=application/pdf;application/x-pdf;application/epub+zip;application/x-cbz;application/oxps;application/vnd.ms-xpsdocument;image/jpeg;image/pjpeg;image/png;image/tiff;image/x-tiff
Categories=Office;Publishing;Viewer;Graphics;
Actions=View
NoDisplay=true
[Desktop Action View]
Name=View with mupdf
Exec=mupdf %f

I can't speak for issue #69, if the user had somehow "hidden" ("deleted") his application desktop entry, then QtFM is entitled to at least not use it for launching. But this is not the case for my entry. It is not listed as "Hidden", it is only listed as "NoDisplay".

The desktop specification is explicit about the behaviour for this, specifically referring to how "file managers" should behave:

NoDisplay means "this application exists, but don't display it in the menus". This can be useful to e.g. associate this application with MIME types, so that it gets launched from a file manager (or other apps), without having a menu entry for it (there are tons of good reasons for this, including e.g. the netscape -remote, or kfmclient openURL kind of stuff).

Absolutely QtFM should respect and use NoDisplay desktop entries, and should absolutely not delete them from the mimeapps.list! Apologies if you find my emphasis confronting, I've been on this all morning :-)

I have left suggestions for what I interpret as "corrections" to behaviour on issue #69, and I beg you to update QtFM to correct this issue as well.

Thank you.

anilsg commented

I will leave another addendum to this report.

I checked to see if removing "NoDisplay" from the MuPDF desktop entry would assist. It did. This is definitely a workaround for this issue.

However I discovered further implications of this behaviour of QtFM to update the mimeapps.list as it sees fit.
Observe:

$ grep pdf mimeapps.list
application/pdf=mupdf.desktop;masterpdfeditor4.desktop;chromium.desktop;gimp.desktop;brave-browser.desktop;firefoxdeveloperedition.desktop;org.photoqt.PhotoQt.desktop
application/x-bzpdf=org.photoqt.PhotoQt.desktop
application/x-gzpdf=org.photoqt.PhotoQt.desktop
application/x-pdf=org.photoqt.PhotoQt.desktop

$ xdg-mime query default application/pdf
mupdf.desktop

$ qtfm

$ xdg-mime query default application/pdf
mupdf.desktop

$ grep pdf mimeapps.list
application/epub+zip=mupdf.desktop
application/oxps=mupdf.desktop
application/pdf=mupdf.desktop;masterpdfeditor4.desktop;chromium.desktop;gimp.desktop;brave-browser.desktop;firefoxdeveloperedition.desktop;org.photoqt.PhotoQt.desktop
application/vnd.ms-xpsdocument=mupdf.desktop
application/x-bzpdf=org.photoqt.PhotoQt.desktop
application/x-cbz=mupdf.desktop
application/x-gzpdf=org.photoqt.PhotoQt.desktop
application/x-pdf=org.photoqt.PhotoQt.desktop;mupdf.desktop
image/jpeg=xfi.desktop;sxiv.desktop;org.photoqt.PhotoQt.desktop;viewnior.desktop;chromium.desktop;gimp.desktop;brave-browser.desktop;mupdf.desktop
image/pjpeg=viewnior.desktop;mupdf.desktop
image/png=xfi.desktop;sxiv.desktop;org.photoqt.PhotoQt.desktop;viewnior.desktop;chromium.desktop;gimp.desktop;brave-browser.desktop;mupdf.desktop
image/tiff=gimp.desktop;xfi.desktop;org.photoqt.PhotoQt.desktop;viewnior.desktop;mupdf.desktop
image/x-tiff=mupdf.desktop

I would suggest that the desktop specification on mime handling might work better if individual applications were more respectful of user preferences as they find them.

Unless I'm badly mistaken, QtFM has read the capabilities it's found in the MuPDF desktop entry and written out the mimeapps.list all over again, making numerous updates, without checking with the user. It seems that QtFM treats the mimeapps.list file as it's own little database, and takes responsibility (away from the user) for keeping it up to date, short-circuiting the user's ability to use the mimeapps.list directly. I would argue this is a contradiction of Linux principles and an unnecessary reduction in flexibility.

Also, I think that QtFM should recognise that it may not be the only file manager in use, as is my case.

At least there could be a "don't re-write mimeapps.list" option, although I never expected any individual application to be so destructive in the first place. Just because an application publishes ability to work with files of a particular mime type in it's desktop entry, it doesn't mean the user has chosen to allow it as a choice.

Also, QtFM could elect, I would suggest, should elect, to only write to mimeapps.list on explicit instruction from the user. Presumably this would normally be indicated by the user pressing "save" in the Edit > Settings > Mime Types dialogue, rather than silently and instantly every time it starts up?

Thank you very much again, for maintaining one of the best file managers available.