Open anilsg opened 1 year ago
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.
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.
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).qtfm
was not running while I edited any filesqtfm
preferences were set to read the rightmimeapps.list
locationmimeapps.cache
files that I founddefaults.list
files that I could findAnd still I got the following behaviour:
~/.config/mimeapps.list
hasmupdf.desktop
as the first entry forapplication/pdf
mimetypeqtfm
and open a PDF file - Master PDF editor is used insteadqtfm
and findmimeapps.list
has changed to removemupdf.desktop
entryExpected behaviour:
~/.config/mimeapps.list
hasmupdf.desktop
as the first entry forapplication/pdf
mimetypeqtfm
and open a PDF file - MuPDF application is usedqtfm
and findmimeapps.list
has not changedTo be clear, the sequence is shown in
bash
here: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). Althoughmupdf.desktop
is available in/usr/share/applications
, sincemupdf.desktop
has been removed by QtFM from themimeapps
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 authoritativemimeapps.list
file from, as I have no othermimeapps.list
ordefaults.list
files (that I can find) on my system.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