Problem with File Associations

English Applications
1

I am running Leap 42.2 and Plasma 5.

I have three different file types that I want to open from Dolphin with three different scripts. I went to Configure Desktop/System Settings > Applications > File Associations, and added Group “text”, Type name “RDP” (one of the three). Then, I edited text/RDP, and added a Filename Pattern (*.rdp). This much works - Dolphin now shows my .rdp files as type “text/RDP”. However, when I right-click on one of my files, “Open With” is blank. If I choose “Open With”, I get the Choose Application dialog, where I can choose my script, and select Remember application association… - it will open my file with my script, but it does not remember this setting. The next time I try, same thing - empty “Open With” list.

I also tried editing text/RDP in System Settings > File Associations > Application Preference Order (which is empty) > Add > pick my script > OK - but nothing shows up in Application Preference Order.

How do I fix this?

2

My understanding is that Open with refers to a built-in catalogue of programs. So, if the program that opens the files is not in the catalogue, Open with cannot find it.

3

I don’t have any trouble opening the files with the script - it just won’t remember my settings.

(This all worked great in openSuse 13.1!)

4

You would have no problem with the script because it will be blindly followed. You asked about Open with. There is an OpenDesktop standard for displaying applications which uses a directory of applications and has the facility to read another directory of extra applications; if KDE uses this, I suspect that the way you can add applications to this directory may have changed.

5

I’m not sure that there is any way of curing this particular problem. I noticed it not long after starting to use Linux, kde but suspect that all desktops are the same.

I had to use ms windows at work and it always had a facility to add scripts / applications to right clicks. It might still have on 10. The reason that they include it is for situations they haven’t accounted for. For instance more for fun than anything else I used the facility to edit a source file, assemble it and then link, all with right clicks. It turned out to be a decent way of working. Quicker than the keyboard or using a console via abbreviations.

Of late KDE has become more complex in this area - they have added ask. Click on a file and if it can execute it will ask to open it or run it. I wanted to always have a couple of applications available via right clicks and couldn’t find any way to do it. A sort of . can be added which defeats the ask but getting apps to always appear in right clicks seems to be impossible.

One thing that may be able to do it is dolphin plugin if you can write one and it can use them. I’ve picked up some where that konq can but I don’t like using apps that can also access the web for this sort of thing. I suspect even ms dropped that.

John

6

A 2nd thought as your problem isn’t the same as the one I wanted to solve. However you may have already tried this.

Have you tried adding you script as an application to the start button menu? I suspect that unless you do that kde will assume that it doesn’t exist so will ask you to select something else probably having to navigate to it.

John

7

I tried to edit that post. If you find that adding the script this way doesn’t help you may need to create a desktop file for it and place it in /usr/share/applications or the one off local.

I’d hope this isn’t needed but the menu’s are now loaded with applications from there via desktop files. They do seem to have left scope for legacy menu items so editing the start button menu and adding it should still be ok,

John

8

if I understood you right you want a text file with a particular extension to be opened with a bash script
a question where is this script?
#1 I think you have 2 choices put the script somewhere in your path and kde should remember it
~/bin (or $HOME/bin) is part of the user’s path
#2 do as ajohnw suggested make a desktop file but don’t put it in /usr/share but in
~/.local/share/applications
see these links for a simple/sample desktop file
https://linuxcritic.wordpress.com/2010/04/07/anatomy-of-a-desktop-file/
https://wiki.archlinux.org/index.php/desktop_entries
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
just edit the exec line to point to your script and edit the MimeType line to text/RDP
and give this desktop file a unique name so it shows in the menu bar (replace RDP Reader/Editor with your script’s name)


Name=RDP Reader/Editor
MimeType=text/RDP;
Exec=/home/<you>/path/to/script/script.sh %F

now even doble clicking on an rdp file in dolphin will open it with your script

9

I feel like screaming. Before kDE4 started I had looked at opendesktop etc and noticed that users should be able to extend menu’s. A dev, a senior one told me “no, not doing that”. I’ve just accepted that as fact.

Looking at the site John H mentioned came up with this tutorial

https://techbase.kde.org/Development/Tutorials/Creating_Konqueror_Service_Menus

Then a look around my machine came up with this directory

/usr/share/kservices5/ServiceMenus/

It looks like the facility shown in the tutorial may still be available so right click options can be extended - for Konq anyway. Other posts on the web suggest that this works with dolphin as well but kde needs restarting in order to detect the change. Or it seems kbuildsycoca5 can be run instead. Similar changes to plasma need a restart as well.

The user’s applications menu seems to extend as A_I suggests, A big mistake in my view when there are different users and or desktop types on a single machine. It would be simpler to handle this if it over rides xgd default settings but those could be changed according to who logs in or it could be that a user menu directory does over ride. Best shut up and post a bit more on isolating desktops when I have tried it. Things in this area are easier if one of them over rides system wide settings,

John

10

I do not think KDE wil “remember” it. It could be that KDE uses the PATH variable like the shell does, but that is not for sure to me.

In any case,using an absolute path (without any typical shell constructs like ~/) is the most likely to work. Like from a crontab and like for every usage that may not use a a login shell to interpret it.

11

I just added a start menu item to launch a shell script. It just dumps xdg setting out in konsole. The only catch needed was to add --hold to the run in terminal options so that it doesn’t close as soon as it’s run. I just navigated to the script and it used it’s location for the run command /home/john/xdg what ever I called it.

It added this to my xdg menu file which in my case is now user local rather than system wide.


   <Merge type="files"/>
   <Filename>xdgsetting.desktop</Filename>

then at the end of the file section


   <Menuname>More</Menuname>
  </Layout>
  <Include>
   <Filename>xdgsetting.desktop</Filename>

I can’t be 100% sure about which lines it added as there is no backup.

It’s added a desktop file for it to $HOME/.local/share/applications. :wink: I used $HOME as this area may not function correctly if ~ is used. Pass I’ve noticed both being used.

John