My system is Mint 19.1 Tessa (Mate desktop), and this is about the binary choice apparently offered when setting which application will be invoked when a file icon with a particular extension is clicked on. I need a way to set this in a way that will invoke the proper program without also causing other files of different extensions, or no extensions, but perhaps of the same "type" to be meaninglessly loaded.

It is easy enough to Right-Click => Open With => and see some choices, including "Other Application", and we may even use a custom command. Unfortunately, this is not forever unless one leaves the checkbox checked - but then, the extension is not exclusively associated with the application.

What is remembered is not the association to a file extension, but some other property which can apply to a many other files of that "type".

In my case, the files have extension .sch, which is a file used by an electronics schematic circuit editor. The internal content of the file happens to be ASCII text characters, though not really meaningful as a normal readable text file. Once set, the application is then also launched on all text files, regardless - even ones with a .txt extension!

I did try the other route, which is Right-Click on file => Properties, and choose the "Open With" tab. It seems to be just another way of doing the same thing. If I select files of extension .sch to be opened by the electronics application, the message along the top of the dialogue specifically states ..

"Select an application to open test_circuit.sch and other files of type "plain text document"

I definitely want a document like <something>.txt to be opened by a text editor. I am trying to have it that associating my schematic design file .sch with the application will not also cause it to be uselessly invoked when I click on a text file, and I am failing, whatever I do!

Is there a way of changing a file's "type" to not be in any broad category, but instead to be only associated with launching the application that uses it?

It occurs to me that there is likely always a need to have the option to temporarily choose some other application from a dialogue. This would allow (say) scripts, or programs to be viewed by a text editor, or programming tool, but which would normally invoke the application that uses it. No doubt there are other situations where the option is needed. It would be nice to have it work as intended, but I do not have the in depth knowledge about how to set this up.

Thanks in advance if you can help.

Disclaimer: I knew as much about this as you until I read your post and did some searching on the web.

The problem here appears to be that .sch has a MIME type that is the same as your text files, perhaps text/plain. You can check this with:

Linux associates the MIME type with the relevant application.

One way, perhaps, to solve this is to create a completely new MIME type and associate it with the .sch extension.

For example: https://coderwall.com/p/qjda2q/creat...o-it-in-ubuntu (ignore the icon section)

Then, hopefully, when you right-click on an .sch file and select an application, the system will associate that MIME type with your chosen application.

Let me know how you get on. If you get it to work, then a list of the steps you carry out would be most useful.

I agree with the above post that you need to create a mime type for the file extension.

Typically linux does not care about extensions and uses the magic number if found to determine what application to use or otherwise as defined in the mime types database. Since your .sch file has no magic number and does not appear to be in the mime types data base it defaults to plain text.

1 members found this post helpful.

Thank you both -and also for the link mime type link.
The example given is the simplest sort.
The recipe was essentially..
1. Where are they?
They can be in all sorts of places, some shared, or not, and even some in a private local folder for some app you compiled yourself. The standard place is in /usr/share/mime/packages where there are a set of .xml files which define a mime type, and an extension. Actually, one level up shows you that the mime folder always has "application" and "packages" sub-folders.
Applications use /usr/local/share/mime to keep text file lists of types, and what are known as globs, and other stuff that gets pulled in from definitions kept in that "applications" folder place. The xml files in there are created automatically by "update-mime-database" DO NOT mess around in there!

2. Steal one
Copy one of the simpler ones, and rename it meaningfully to be the one for your application. You will not be able to resist opening others with Text Editor. Be impressed by network.xml. Figure out that libreoffice.xml does something special also using /usr/share/mime-info. Look at them all. It is instructive!

3. Edit the example xml.
Next is to edit it to give the new file type a name, and to set the extension by defining what is called a glob pattern. One could use sudo xed <path_to_file>. I took the probably not recommended way of sudo su, then caja, and then copy-paste and edit at will.

Here is an example from a CAD application..
4. More on editing the shamelessly ripped off example..
a) The first two lines seem to be the same in all of them.
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>

b) The third line is where the mime type name is defined. My application command launches "lepton-schematic"example You use the name of your application.

c) I cheerfully dumped the "<!-- <sub-class-of type="application/zip"/> -->" line.
BUT .. I see that that very line appears unchanged in many of the .xml files.
It is just that I don't yet understand it, though I can see what it implies.

We end up with my edited version..
5. Update the mime database
It may be that one can update the mime database to include other places where there is shared mime information (and icons), because I found some. Be aware that mime setups can get absurdly complicated, and capable of generating unpredictable conflicts. More on this later. We shall stick with the simple one.
6. Steal or make an icon
Here you can put the icon in /usr/share/icons/<somewhere>.
You have the choice. If you have an svg (scalable) icon, then putting it in..
/usr/share/icons/gnome/scalable .. is a candidate.
It does not have to be, and you may not want to get into making fixed icons for all the various sizes as well.
In this case, we would then do ..
You can, of course, use this command, varied, to aim at icons in other places.

7. Your compiled application may have it all somewhere else already!
If your app came from the distro supplied repository, and you installed using
sudo apt-get or Synaptic, then the mime stuff will be pre-installed in the standard places. I have discovered that my application, which I compiled from source, installed in a folder in my $HOME directory, and has inside it a whole folder called "share", with sub-folders "doc" and "icons" and (Yay!), one called "mime". It contains a whole structure looking exactly like the one seen in /usr/share/mime. In there is a far more sophisticated version of xml, using pattern matching, and a bunch of icons that change depending on the context.

I hesitate to put an example here, but I will anyway. Be impressed by what the real deal for my app should have looked like. Here we discover that a single .xml file can provide for multiple commands under the same application umbrella.
Example
It does not take much to find really clever versions that exploit what mime can do rather more, such as the one for musescore (musical score edit) application. This one apparently selectivly adds arguments to the command, depending on the file extension.
This one is more capable
8. Avoid a conflicts!
OK - so the bare-bones simple version works, BUT..
What happens if you define a file-type that is already defined?
This can happen if you installed (say) a version of your application from the repository that was a bit old (e.g. from a Ubuntu LTS), and you wanted to compile the latest.
So you fetch it from a git clone master, and compile away, and the "new" one now needs to be invoked when the target file is clicked.
I THINK this is taken care of when one updates the mime database, BUT - I don't really know. I am already far out of my depth, and I know MIME can be complicated.

I have included some examples here for orientation, to let you know what you might be getting into, and maybe simply because I am overwhelmed. There are some who hold the view that MIME should have been strangled at birth!

Even if you make the simple one, and it works - do not imagine there is not the potential to make a big mess here. I know I have set out some steps, and it seemed OK, but I have to rely on experts at LQ who might have some good advice here, particularly on what not to do. I freely admit that meddling with all the above may not be safe!

My route now has to be how to provide the correct setup for my application, so that it uses all the nice worked out MIME files provided. Maybe all I have to do is update the MIME database, using the command given in (5), or maybe copy what was supplied into /usr/share/mime. All this I don't yet really know. What is here is how to do a simple one. It may not be appropriate to force it on a sophisticated application. For this, if there are those at LQ who know - then do tell!

So, keeping things simple by forgetting the application-supplied MIME Type file for the moment, when you added your new MIME Type and then right-clicked on a sample .sch file, were you able to associate that MIME Type with your chosen application?

I can confirm that the simple version apparently works.
That is not the same thing as saying it was altogether "right", because the mime database update provokes a message that might have happened anyway. Keep in mind that I tried this with a zero-to-marginal understanding of how MIME works!
If I click on a .sch file, the application comes up. If I click on a text file, the Text Editor (xed) comes up.
It definitely all works!
Hmm.. I only just noticed that Pluma is no longer the text editor in Mint 19.1

Thanks. Just a note that I don't get that error/warning on my Mint 19.1 MATE system. A quick scour of the web shows however that you are not alone (the problem has been reported cross-distro) and that the system seems to get on fine all the same.

If you want to chase it up, let me know which files you have in /usr/share/mime/packages and I'll compare them against mine.

I will be checking on exactly how the configuration options for my compiled application are supposed to use the set of mime packages xml files supplied, particularly, where they are supposed to live, and how the mime data base gets to know this.

Presently in my /usr/share/mime is what amounts to a partial list of the programs I have loaded, plus some that came with the distro. Some will be the same as yours, libreoffice.xml for example

audacity.xml -- -- -- -- -- -- Audio processing
caja.xml -- -- -- -- -- -- -- -- The file manager
freecad-daily.xml -- -- -- -- CAD design
freedesktop.org.xml - - -- ? It was there when I first looked
gcr-crypto-types.xml - -- - Apparently for digitally signed stuff
kde.xml -- -- -- -- -- -- -- --- KDE stuff arrived when I installed Kalzium
kde5.xml - -- -- -- -- -- -- -- .. and maybe kdiff3 file comparing utility
kpatience.xml -- -- -- -- -- .. and maybe the solitare game
lepton-schematic.xml -- -- The electronics design package
libreoffice.xml -- -- -- -- -- - It's huge, and uses /usr/share/mime-info as well!
mate-theme-package.xml -- -- Themes
musescore.xml -- -- -- -- -- -- For music scores
network.xml ---- -- -- -- -- -- -- Also big, dealing with inode types and icons
tomboy.xml -- -- -- -- -- -- -- -- Apparently about .note extensions for x-note, which I did not know was there.
tuxguitar.xml - -- -- -- -- -- -- -- Audio processing for electric guitar.

I expect you will have the same default set that came from the repository, plus others that would be for your installed favourite applications.

Ok, thanks. The ones you have that I don't have are: freecad-daily, kde, kde5, kpatience, lepton-schematic, musescore, network, tomboy and tuxguitar.

However I did read somewhere that KDE was linked to the Unknown media type message.

So, you could move the 2 kde files somewhere safe and run an update of the MIME database as you did before to see if the message is generated. You can always move the 2 files back afterwards and run the database update again to return to how you were before.

OK - I don't mind experimenting a bit with the Mint 19.1 installation.
It is the newest, and I am booting it as a grub option to the standard Mint 18.3 Sylvia, which I still use while I set up and test email clients, remote desktops, and get everything to a state where I can safely move on, and get used to the next girl's name.

Before I move KDE mime package files around, I looked also at the MIME packages in the 18.3 Sylvia version.
These naturally reflect the software choices wanted at the time. Things like the video editing tool Kdenlive, or the DVD burner K3B.

In both systems, I notice a runaway set of Okular choices when I use the "Open With" dialogue. I had installed Okular, the KDE-based PDF viewer, just because I liked some of it's features. The system had the same uncertainty about which to application to invoke as we saw previously about text files. Is it to be Document Viewer, or Okular that gets to take on PDFs?
In an attempt to make make the choice permanent, I chose the "Other Application" dialogue. The Okular application choice is repeated 13 times! What is going on here? A strange thing, but they all seem to work harmlessly, so I leave it alone.

I will try your suggestion next opportunity I have when I get back on Mint 19.1

Attached Thumbnails

 

That's how I do things as well, although I usually get on board with the new major beta version, e.g. I'll create the dual boot when Mint 20 beta (yet another girl's name - Ursula perhaps? ) comes out - by the time it comes out of beta, I'm usually ready to migrate over from the previous version. That also helps me provide beta feedback to the Mint developers, but may not be to the taste of all. Once Mint gets to beta, it's in pretty good shape already.

I tend to leave things alone as well, if I haven't found anything with a search of the web, but that does seem strange indeed. In saying that, I tend not to install KDE software on my MATE system in the aim of keeping things clean (those KDE dependencies can mount up).

hydrurga: OK - I did make the KDE MIME .xml files in /usr/share/mime/packages/ become un-see-able. I chose to temporarily rename them, and their extensions by surrounding them with ampersands, e.g. &kde.xml.&

I can confirm that when I ran .... there were no "Unknown media type" messages.

When I restored the two KDE .xml filenames back to their originals, and tried the command again, the messages were back! Very likely one message line per filename.I know there are things one can do to carefully set up compatibility for running KDE applications in a gtk desktop, and I suppose vice-versa, but I do like the Okular PDF viewer "middle-click-hold->zoom with mousewheel" feature, and the pile of tools to rotate, copy-selected-to-clipboard, or as image, and so on. I guess I just got fond of it compared to the sparse "Document viewer"

Digging into how MIME works here:
The messages complain of missing media types in 'all/all' and in 'all/allfiles'.
These are .xml files that live one level up, and appear to be identical.
They were created automatically by the update-mime-database command, and have the warning "DO NOT EDIT"! A little snippet from the top few lines of allfiles.xml is..Looking at the second line kind of looks like the update command shot itself in the foot creating the unknown media type that is so "unknown" all by itself! .. BUT that is probably unfair and wrong, because I don't really understand it yet.

We discover more by going back down a level into /usr/share/mime/packages, and looking at, and comparing the content of kde.xml and kde5.xml. They clearly take some of the content from all.xml, with advice about considering putting additions elsewhere.

This only happens to those who run KDE stuff
That may number possibly a great many, who, like me, would use a few nice things they found in the repository, which happen to come from the KDE stable.

I think we do not have to worry too much about it. Nothing breaks! The simple edit to teach the system a new filetype to associate with the wanted application does work. Use it if all else fails. It seems easy enough to use the dialogue to permanently associate a fileype extension with a wanted application if it has been installed in the normal way. I did this to have Okular be used instead of Document Viewer, for example.

If you install an application some other way, say compile from source, then the install script may or may not be slick enough to add in it's .xml file, and create the right rules for the (new) extensions it may use. Some sources come with with a whole set of MIME support related folders, though how they are properly used may vary.

Is it shared?
There may be a difference between .xml files placed in /usr/shared/mime/packages, and having a private setup for such files if they are not "shared". For me, simply hacking a donor .xml file, and forcibly creating the extension and association was an OK fix.

Cheers for the info, GTrax. I know this subject is finished (you can mark the thread "Solved" through the Thread Tools menu at the top of the thread, by the way), but if you get a moment to paste the contents of kde.xml then I would be interested in looking at them.

hydrurga: OK then, here they are.
I suspect some of these files may be able to refer to each other, and given that the inclusion of kde.xml and it's companion kde5.xml both managed to trigger a complaint from the update tool that referenced .xml files up in /usr/share/mime/all, they must be related somehow. Perhaps the "all.xml" and "allfiles.xml" are automatically created when the distro is installed, and the later interlopers like kde.xml are not recognized because their file-types are not in the list that gets checked first.
I have renamed the files with a .txt extension to allow them to upload.

-----------------------------------------

We have let this thread trawl only some of the ways MIME filetypes work, and within a Linux context at that!. The idea here was to get to a fast practical way of getting a system to recognize an extension, and bring up the appropriate application, without having to become expert in all the ways of MIME.

Stay with the simple recipe!
Even a casual search for "MIME filetype" will bring up big lists of MIME filetypes, and a tangled world of Windows files that have extension ".mime". I wonder what recursive mechanism registers the extension of the file that is defining the extensions! I do not have enough life left to use it up on learning MIME. I shall stay with the simple recipe of renaming a copy of a .xml file in /usr/share/mime/packages, and then substituting the extension(s), and the application name in the right place, and deleting all other content.

Attached Files

	kde.xml.txt (244.7 KB, 26 views)
	kde5.xml.txt (209.3 KB, 6 views)
	all.xml.txt (3.9 KB, 12 views)
	allfiles.xml.txt (3.1 KB, 12 views)

1 members found this post helpful.

Quoting myself here". Windows uses the file extension as the way of knowing what to do. Linux and Mac OS do not need to! Here is a link to an explanation.
https://www.howtogeek.com/192628/mim...le-extensions/

I think we Linux users have it easy in comparison!

1 members found this post helpful.