Confusing .desktop files

[MochiMoppel]

This is something I noticed in @radky 's BW64, but other distros are affected as well.

Most .desktop files are stored in /usr/share/applications and I wonder if the ones which are scattered in other locations wouldn't be easier to maintain if they also would be transfered to /usr/share/applications, then symlinked as needed.

Some of these are duplicates and - maybe - there is a good reason to have 2 of each. Not really my business.
/usr/local/apps/PackIt/PackIt.desktop
/usr/share/applications/PackIt.desktop

/usr/local/takeagif/tkagif.desktop
/usr/share/applications/tkagif.desktop

/usr/local/apps/UExtract/UExtract.desktop
/usr/share/applications/UExtract.desktop

However there is a crucial difference in UExtract.desktop:
/usr/local/apps/UExtract/UExtract.desktop contains a MimeType key:

Code: Select all

MimeType=application/dicom;application/epub+zip;application/gzip;application/img;application/initramfs-gz;application/mbox;application/ms-tnef;application/pdf;application/pet;application/pup;application/vnd.adobe.flash.movie;application/vnd.android.package-archive;application/vnd.appimage;application/vnd.chess-pgn;application/vnd.comicbook-rar;application/vnd.comicbook+zip;application/vnd.debian.binary-package;application/vnd.etsi.asic-e+zip;application/vnd.flatpak;application/vnd.ms-cab-compressed;application/vnd.ms-excel.sheet.macroEnabled.12;application/vnd.ms-powerpoint;application/vnd.ms-tnef;application/vnd.oasis.opendocument.chart;application/vnd.oasis.opendocument.database;application/vnd.oasis.opendocument.graphics;application/vnd.oasis.opendocument.graphics-template;application/vnd.oasis.opendocument.image;application/vnd.oasis.opendocument.presentation;application/vnd.oasis.opendocument.presentation-template;application/vnd.oasis.opendocument.spreadsheet;application/vnd.oasis.opendocument.spreadsheet-template;application/vnd.oasis.opendocument.text;application/vnd.oasis.opendocument.text-master;application/vnd.oasis.opendocument.text-template;application/vnd.oasis.opendocument.text-web;application/vnd.openofficeorg.extension;application/vnd.openxmlformats-officedocument.presentationml.presentation;application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;application/vnd.openxmlformats-officedocument.wordprocessingml.document;application/vnd.rar;application/vnd.sqlite3;application/vnd.squashfs;application/vnd.sun.xml.calc;application/vnd.sun.xml.calc.template;application/vnd.sun.xml.draw;application/vnd.sun.xml.draw.template;application/vnd.sun.xml.impress;application/vnd.sun.xml.impress.template;application/vnd.sun.xml.math;application/vnd.sun.xml.writer;application/vnd.sun.xml.writer.global;application/vnd.sun.xml.writer.template;application/x-7z-compressed;application/x-abiword;application/x-ace;application/x-aes;application/x-alz;application/x-amiga-disk-format;application/x-amipro;application/x-apple-diskimage;application/x-arc;application/x-archive;application/x-arj;application/x-bfe;application/x-blender;application/x-btrfs-image;application/x-bzip;application/x-bzip-compressed-tar;application/x-cb7;application/x-cbr;application/x-cbt;application/x-cbz;application/x-ccrypt;application/x-cd-image;application/x-chm;application/x-compress;application/x-compressed-tar;application/x-cpio;application/x-cpio-compressed;application/x-dar;application/x-deb;application/x-debian-package;application/x-doom-wad;application/x-emerald-theme;application/x-ext2-image;application/x-ext3-image;application/x-ext4-image;application/x-font-pcf;application/x-gamegear-rom;application/x-gettext-translation;application/x-gnumeric;application/x-gz-font-linux-psf;application/x-gzip;application/x-gzpdf;application/x-gzpostscript;application/x-hwp;application/x-initrd;application/x-initrd-compressed;application/x-iso9660-appimage;application/x-java-archive;application/x-java-pack200;application/x-lha;application/x-linux-kernel;application/x-lz4;application/x-lz4-compressed-tar;application/x-lrzip-compressed-tar;application/x-lzip;application/x-lzip-compressed-tar;application/x-lzma;application/x-lzma-compressed-tar;application/x-lzop;application/x-matroska;application/x-mimearchive;application/x-ms-dos-executable;application/x-ms-wim;application/x-navi-animation;application/x-nsv;application/x-ole-storage;application/x-pak;application/x-php;application/x-rar;application/x-raw-disk-image;application/x-raw-disk-image-xz-compressed;application/x-rpm;application/x-shar;application/x-sharedlib;application/x-shockwave-flash;application/x-sms-rom;application/x-source-rpm;application/x-sqlite3;application/x-squashfs-image;application/x-tar;application/x-tarz;application/x-truecrypt;application/x-tzo;application/x-veracrypt;application/x-virtualbox-ova;application/x-virtualbox-vbox-extpack;application/x-virtualbox-vdi;application/x-virtualbox-vmdk;application/x-windows-themepack;application/x-xar;application/x-xoj;application/x-xpinstall;application/x-xz;application/x-xz-compressed-tar;application/x-zstd-compressed-tar;application/x-zoo;application/zip;application/zstd;audio/basic;audio/mpeg;audio/x-flac;audio/x-m4b;audio/x-mo3;audio/x-ms-wma;audio/x-wav;audio/x-wavpack;font/collection;image/bmp;image/gif;image/jpeg;image/ktx;image/png;image/svg+xml-compressed;image/vnd.djvu;image/vnd.djvu+multipage;image/vnd.microsoft.icon;image/webp;image/x-dds;image/x-icns;image/x-win-bitmap;image/x-xcursor;message/rfc822;text/x-vhdl;video/3gpp;video/mp2t;video/mp4;video/mpeg;video/ogg;video/quicktime;video/webm;video/x-flv;video/x-matroska;video/x-matroska-3d;video/x-msvideo;video/x-ms-wmv;

In /usr/share/applications/UExtract.desktop this key is missing. This is the reason why Uextract, my preferred extractor , never appears in the ROX right-click menu. If it *would* be present then the update-desktop-database script would scan this file and would update /usr/share/applications/mimeinfo.cache, which would be read by ROX for its right click menu. On the other hand the MimeType key in /usr/local/apps/UExtract/UExtract.desktop has no effect because update-desktop-database ignores this file.

It's easy to fix and IMHO it should be fixed. It will not only affect ROX but e.g. in BW64 would put Uextract into the OpenWith choices ot Fsearch.

[rockedge]

There is a main difference between .desktop files being in /usr/share/applications and a location like /root/.local/share/applications.

For example we need a run-as-spot modification to the Exec= line in a .desktop file and an update then occurs involving the package that the .desktop file launches.

It is very possible that the .desktop file in /usr/share/applications will be overwritten and replaced removing the run-as-spot modification. To allow a good clean update that would perform that action, placing a copy in /root/.local/share/applications would preserve the modified .desktop file.

.desktop files in /root/.local/share/applications take precedence over /usr/share/applications.

Then in /home/spot/.local/share/applications for example that same .desktop file could have a different modification specifically for user spot, that would have precedence over the .desktop file in /usr/share/applications

Hopefully that makes sense how I explained it!

[MochiMoppel]

@rockedge How does this explain the decision to add a MimeType key to one UExtract.desktop and not to the other?
And why are the 3 applications the only applications among dozens of others that place an extra .desktop file into their ROX application folder?
And why is this done for Takeagif and not for the almost identical Takeashot?

You don't need to answer this, it's not that important. I can live with it but many questions remain.

There is a main difference between .desktop files being in /usr/share/applications and a location like /root/.local/share/applications.
<snip>
Then in /home/spot/.local/share/applications for example that same .desktop file could have a different modification specifically for user spot, that would have precedence over the .desktop file in /usr/share/applications
Hopefully that makes sense how I explained it!

There is neither a /root/.local/share/applications nor a /home/spot/.local/share/applications folder in BW64, which makes it all the more confusing

[Edit1] In case of UExtract.desktop I now partly understand the intention. The script /usr/local/apps/UExtract/createshortcut can be used to create a desktop shortcut. It also uses /usr/local/apps/UExtract/UExtract.desktop (the one with the MimeType) to put a copy of it into $HOME/Desktop. Apparently useful when env variable XDG_DESKTOP_DIR="$HOME/Desktop" is set, In BW64 it is not.

[Edit2] @JakeSFR Maybe you can shed some light on this? The UExtract pet puts a .desktop file without MimeType into /usr/share/applications and then uses the pinstall.sh script to extract MimeTypes from the local .desktop file in the ROX App folder to create/populate the folders in /root/.config/rox.sourceforge.net/SendTo, e.g. put a link into /root/.config/rox.sourceforge.net/SendTo/.video_ogg
If the pinstall.sh is not run from / or is not run at all, these folders are not created or remain empty. This is the actual situation in @radky's BW64. Don't know if this a bug or has other reasons. In F96-CE it is correct. What is the reason to not include MimeTypes in /usr/share/applications/UExtract.desktop and instead rely on the pinstall.sh script and use ROX's harder to maintain (and IIRC deprecated) SendTo folders?

[JakeSFR]

[Edit2] @JakeSFR Maybe you can shed some light on this? The UExtract pet puts a .desktop file without MimeType into /usr/share/applications and then uses the pinstall.sh script to extract MimeTypes from the local .desktop file in the ROX App folder to create/populate the folders in /root/.config/rox.sourceforge.net/SendTo, e.g. put a link into /root/.config/rox.sourceforge.net/SendTo/.video_ogg

Yes, you've got it right.

If the pinstall.sh is not run from / or is not run at all, these folders are not created or remain empty. This is the actual situation in @radky's BW64. Don't know if this a bug or has other reasons. In F96-CE it is correct.

Not sure why it happens. Petget (or whatever there is in BW64) should cd / before executing a pinstall.sh script.
At least that's the way it always was, as far as I can remember.

/usr/local/petget/installpkg.sh in Slacko-5.7.0:

Code: Select all

#post-install script?...
if [ -f /pinstall.sh ];then #pet pkgs.
 chmod +x /pinstall.sh
 cd /
  LANG=$LANG_USER sh /pinstall.sh
 rm -f /pinstall.sh
fi

What is the reason to not include MimeTypes in /usr/share/applications/UExtract.desktop and instead rely on the pinstall.sh script and use ROX's harder to maintain (and IIRC deprecated) SendTo folders?

For a brief period the MIME types were in the main .desktop file in usr/share/applications, but it turned out that other applications (like Firefox) pick it up and suggest to open every supported file with UExtract, which was annoying to some users (including me).

Btw, I could've used a plain text file, or embed the MIME types in pinstall.sh, but I used the .desktop file in /usr/local/apps/{UExtract,PackIt} just on a whim and for "completeness" of the AppDir, knowing that no part of the system should be able to access it accidentaly.

"[...] harder to maintain" than what? OpenWith, or is there a completely new way of adding right-click options to ROX in Puppyland now (wasn't paying attention lately)?

Greetings!

[MochiMoppel]

For a brief period the MIME types were in the main .desktop file in usr/share/applications,

Good.

but it turned out that other applications (like Firefox) pick it up and suggest to open every supported file with UExtract,

Sure, but that's the whole point of registering the MIME types in the system. Every application can consult the MIME database and find out, which applications claim to support a certain MIME type. As already mentioned, Fsearch and probably other file managers pick them up and that's a good thing.

which was annoying to some users (including me).

???
No matter what,"some users" will always complain. Satisfied users are silent It's hard to get annoyed by Firefox because the default is to download a document. If a user deliberately opts to be asked what to do with it, then poor Firefox will yell into the round "Anybody here knows how to open this epup thing?". Then UExtract will jump up "Me! Me!". Since nobody else comes forward Firefox will propose UExtract as the handler for an epup document. What else should it do? It can't know that the user expects to read the document, not to take it apart.
Is this the "annoyance" you are talking about? If so then the "annoyance" is only postponed with your decision to hide the MIME type from the system. When the user right-clicks the downloaded document he will get UExtract as the only application to open it (I'm currently in F96-CE). Reason to be annoyed again?

One way to avoid such misunderstanding could be to limit the registered types to those normally associated with an archive extractor, i.e. zip, tar and companions. Office documents, though technically containers, are meant to be read, and here UExtract would not be the right application. Weird users like me, who occasionally want to take them apart, usually don't need the assistance of the right-click menu. And then there are some strange types claimed by UExtract, e.g. image/png or image/jpeg, which may be useful for rarely encountered PNG or JPG variants (and then only if additional tools are installed). It hardly justifies to present images with an option to open them with UExtract.

I'm convinced that with some tweaking everybody wins.

[JakeSFR]

Is this the "annoyance" you are talking about? If so then the "annoyance" is only postponed with your decision to hide the MIME type from the system. When the user right-clicks the downloaded document he will get UExtract as the only application to open it (I'm currently in F96-CE). Reason to be annoyed again?

Well, both UExtract and PackIt are meant primarily as ROX right-click apps, so there's no postponing anything, everything's as intended. And they definitely weren't designed as Firefox's or anything else's handlers.

One way to avoid such misunderstanding could be to limit the registered types to those normally associated with an archive extractor, i.e. zip, tar and companions.

That might be an acceptable approach. I'll put this idea on my TO-DO list.

Greetings!