Hi there,

since Debian Sid finally made the move towards KDE 4.2, I'm now facing a whole new bunch of applications (dolphin, gwenview, okular...) which I am eager to explore in order to experience the praised new and improved user experience...

In this context, an issue re-emerged that I've already been wondering about at some occasions in the past: Is there a way to define a default behaviour for a whole bunch of mime types, like the mime type categories defined in the "File Associations" dialog of the systemsettings (or formerly kcontrol) application? For instance, imagine I'd like to use gwenview as default app for *all* kinds of image files. Is there another way to make dolphin open gwenview when (double-)clicking such a file apart from going through all the ~100 image mime types and individually place gwenview on top of the helper application list? (I'm aware that gwenview might not be capable of displaying *every* image format in the world, but I suppose it would be a good default app. And I could well live with the occasional requirement to manually edit some file association in those rare cases in which gwenview fails.)

Side question: I understand that dolphin doesn't support embedded file previewing. To this end, the "Embedding" tab in each mime type's settings doesn't make any sense in this context?

Best regards --

tcrass

Konqueror ( and any KParts application ) will automatically follow the embedding settings. Dolphin is not based on KParts as far as I know.

Unfortunately, I do not believe it is possible to redefine all mime type applications at once.

Hi bcooksley,

bcooksley wrote:Konqueror ( and any KParts application ) will automatically follow the embedding settings. Dolphin is not based on KParts as far as I know.

yea, that's what I thought, too.

bcooksley wrote:Unfortunately, I do not believe it is possible to redefine all mime type applications at once.

Noooooo.....! But I assume those settings must be stored in some kind of configuration file which could be automatically modified by a (shell, Perl...) script? Does anyone know the path(s) to this/those file(s)? (I've already spent several hours searching the web for a description of how KDE manages its file associations, but I didn't find anything useful...)

Regards --

tcrass

They are stored in configuration files. You should be able to find them in either ~/.local/share/applications or $KDEHOME/share/applnk.

Not sure what they are called however.

Hi bcooksley,

bcooksley wrote:They are stored in configuration files. You should be able to find them in either ~/.local/share/applications or $KDEHOME/share/applnk.

Not sure what they are called however.

those .desktop files in ~/.local/share/applications indeed seem to contain some information about which mimetypes those apps are capable of handling. Not sure though what $KDEHOME referst to -- I don't have such a variable in my environment, and the only applink directory on my system is in /usr/share. This seems to relate to freedesktop.org's shared MIME info database. I understand that KDE 4 also makes use of this mechanism? If so, tools like xdg-mime should be able to tell me which application will be used for opening files of a certain type, right?

KDE/Dolphin, however, seems to handle things somewhat differently. For instance,

Code: Select all

xdg-mime query default image/png


tells me that iceweasel is assigned to png images, in spite of the fact that I assigned gwenview as default app which gets open when (double)-clicking a png file in dolphin.

So does anybody know where to find information about KDE 4's MIME type handling?

Regards --

tcrass

The environement variable $KDEHOME is unfortunately not always set. It can be retrieved through the following command:

Code: Select all

kde4-config --localprefix

I do not know how much KDE applications integrate into the XDG mime database. KDE applications use the KSycoca, which is a cache of information about all installed applications, associations, plugins, themes, etc. It is built by "kbuildsycoca4" which is executed on startup or when kded ( KDE Daemon ) detects a change in one of the locations where desktop files are stored, to refresh it. It is responsible for reading all *.desktop files in known locations to build this essential cache. KDE applications cannot function in most cases without it.

I have no idea how it decides which is the most important application though, or where the data is stored which determines the order. It is likely in ~/.local/share/ somewhere.

Hi,

bcooksley wrote:The environement variable $KDEHOME is unfortunately not always set. It can be retrieved through the following command:

Code: Select all

kde4-config --localprefix

ah, right, ok -- however, this only yields my personal ~/.kde, and I just can't find anything useful there with regard to file associations as observed within dolphin.

bcooksley wrote:I do not know how much KDE applications integrate into the XDG mime database. KDE applications use the KSycoca, which is a cache of information about all installed applications, associations, plugins, themes, etc. It is built by "kbuildsycoca4" which is executed on startup or when kded ( KDE Daemon ) detects a change in one of the locations where desktop files are stored, to refresh it. It is responsible for reading all *.desktop files in known locations to build this essential cache. KDE applications cannot function in most cases without it.

I have no idea how it decides which is the most important application though, or where the data is stored which determines the order. It is likely in ~/.local/share/ somewhere.

Well, in both /usr/share/(applnk|mime) and ~/.local/share I find a lot of stuff that pretty much looks like it belonged to the XDG mechanism, but nothing that seems related to the mentioned dolphin behaviour.

But there just *must* be a way to alter dolphin's associations programmatically!

Any idea where else one could ask questions about this topic?

Regards --

tcrass

There is a way to alter the associations, but you will either:
A) Have to write an application to use KDELibs to make the changes in bulk.
B) Do all of the changes manually through Dolphin.

As far as I am aware there is no way currently to make large changes with the existing applications.

bcooksley,

bcooksley wrote:There is a way to alter the associations, but you will either:
A) Have to write an application to use KDELibs to make the changes in bulk.
B) Do all of the changes manually through Dolphin.

As far as I am aware there is no way currently to make large changes with the existing applications.

thanks for your patience and your detailed replys. Since I am not really willing to learn in-depth KDE programming for performing such a seemingly simple task, I guess I am currently stuck with the situation. To this end, I hope you don't mind me *not* marking this thread as solved, do you...?

Regards --

tcrass

Can we make a feature request to simplify updating mime type categories? we (www.gtisoft.com) provide our engine simulation tools across platforms and it would be nice to have something to simplify this task. If there is something not too hard on this topic that someone can direct me to, please forgive the post and thanks. I was unable to find such a beast.

We create the file associations when installing on windows, but we do not have enough users on linux to justify significant effort for this. (most of our linux users do not use a desktop, but rather just a terminal for the solver part of our application)

Thanks.

Feature requests for KDE should be directed to bugs.kde.org.

Note that the KDE interface simply changes underlying files, I do not know what they are, however they likely follow a FreeDesktop.org specification however. In order to share the work between the various free desktop's, I would recommend changing these files instead.

Sorry to revive an old thread, but does anyone know if this is being worked on? It's something which in some cases can quickly turn from a "that would be nice if ... " to the behavior of a complete showstopping bug.

From what I've seen the general behavior seems to be that whatever application you've installed most recently will become the preferred one. I've found the issue to be the most irritating with audio and video files, where one might want to install multiple viewers, editors, etc. for different situations.

For example, one might want to use the distro's default player (such as Dragon), or something else standard like VLC, for most media files; but then need something like RealPlayer for a few specific formats. RealPlayer can accept many other MIME types, but there's no earthly reason anyone would ever want to use it unless there is absolutely no alternative to play one of their cruddy proprietary files in an encumbered and obsoleted codec. Installing RealPlayer means you have to manually go and delete it out of the file associations for many MIME types which makes one want to scream.

Come to think of it this could be considered a bug in RealPlayer, more than an issue in KDE, no?

Another example: Wine has the ability to open text files (I guess in Notepad, or something?) But installing Wine then sometimes means that every .txt, .py, .cpp, etc. tries to launch wine instead of Kate or something else reasonable.

As far as I am aware, no work has been done.

I just installed KDE for the first time in years, and am generally very impressed. But I must say I'm a little bit shocked that this can't be done in KDE. I seem to remember even XFCE having this feature when I tried it more than a year ago.

Coming from a more minimalistic setup (Openbox and the like), I never thought much about these things, but in a point-and-click centric environment like KDE easy control over default applications is absolutely vital.

For anyone interested, this was submitted through brainstorm here, and by popular request submitted to bugs.kde.org here.

And if anyone have figured out where these things are stored, please do share. I die inside a little every time I see that "Open with Notepad" that comes after installing Wine.

These settings are defined in the *.desktop files for applications, which is then matched against a seperate list of mime-types, and matching information. As such, adding a global default for a whole category may have unintended consequences.