Hello, all. We make extensive use of Kiosk mode to manage our KDE 3.5.10 desktops on Debian Lenny. When we've needed to change file associations, we've edited the central profilesrc file. How does one set which applications are offered to open files of mime-type application/x-zip in Kiosk mode?

We are running into the .docx file association problem. Ideally, we would like Konqueror to see these as application/msword and added .docx to that definition. However, it appears that peering into the file contents takes precedence and Konqueror insists on seeing them as application/x-zip (although file --mime-type <somefile.docx> shows application/zip - I don't know why there is a difference).

So we thought we would add OpenOffice Writer and Calc as right click open options. We added the following to our central profilerc:

[application/x-zip - 1]
AllowAsDefault=true
Application=kde-ark.desktop
GenericServiceType=Application
Preference=3
ServiceType=application/x-zip

[application/x-zip - 2]
AllowAsDefault=true
Application=openoffice.org-writer.desktop
GenericServiceType=Application
Preference=2
ServiceType=application/x-zip

[application/x-zip - 3]
AllowAsDefault=true
Application=openoffice.org-calc.desktop
GenericServiceType=Application
Preference=1
ServiceType=application/x-zip

[application/x-zip - 4]
AllowAsDefault=true
Application=ark_part.desktop
GenericServiceType=KParts/ReadOnlyPart
Preference=1
ServiceType=application/x-zip

That has always worked for other file types. Alas, it does not for x-zip files. We do not see the context menu open with options and checking Konqueror settings does not show the association. We tried on several users and ensured we had logged in with fresh sessions and there was no local .kde/share/config/profilerc file.

We also tried making the same entries with application/zip because of the discrepancy noted above but that did not help either.

Oddly, on the two stations where we made the change to add Writer and Calc as options for x-zip files in order to see what changes we needed to make to profilerc, after we deleted their profilerc and logged in again, they continued to show Writer and Calc as x-zip file options. So it appears the information for x-zip associations must be stored someplace other than profilerc.

I've gone through the local .kde files for these two users file by file but cannot find why they show the options while others do not.

So, how does one set which applications are offered to open files of mime-type application/x-zip in Kiosk mode? Thanks - John

It is possible that *.desktop files located under either ~/.local or ~/.kde are creating this new association...

Thanks for the pointer but it doesn't seem to be the case. I checked one of the two desktops where we originally made the change and where it still works. There are entries under .local/share/applications but nothing for either zip or docx.

There is nothing locally under .kde/share/mimelnks/application

We did have an entry in the central share/mimelnks/application for x-zip.desktop with contents:

[Desktop Entry]
X-KDE-AutoEmbed=false

I removed it just in case and tried logging in as one of the users who do not receive the new open with options and it did not fix the problem. They still only have Ark as an option and not Writer and Calc.

What else might I be doing wrong? Thanks - John

Have you checked under ~/.kde/share/services/ also?

I only see nsplugin.desktop - John

Please try checking ~/.local/share/applications/mimeapps.list

Thanks for the very prompt responses - very much appreciated as I've been up all night fighting with this problem. I have no such file on my system (which shows the open with options) nor do those systems which do not have the open with options - John

I've checked with an KDE 3 system, and it copies the *.desktop file of the application which is being added to an assocation to ~/.local/share/applications/ and modifies the MimeType line appropriately.

This method seems to override profilerc ( which probably determines order only )

Oh, I see it now that you point it out. I suppose that leads to the next question - is it possible to manage the .local files in Kiosk mode? We use KDEDIRS to manage the .kde set of files but I'm not familiar with how to do that for .local. Thanks - John

~/.local/share/applications can be KIOSK managed by changing any of the files in <root>/share/applications, where <root> is one of the entries contained in KDEDIRS

Note that earlier entries override later ones ( as it looks for the file and stops when it is found )

Argh!! I thought for sure this was the answer but it doesn't seem to work. For example, I just checked a user with this setting:

KDEDIRS=/data/.Common/kde3profiles/clientadmins:/data/.Common/kde3profiles/winusers:/data/.CommonClient/kde3profiles/allusers:/data/.Common/kde3profiles/default:

Under /data/.Common/kde3profiles/default we have:

drwxr-sr-x 6 root Eng-a100 4096 May 15 19:40 share

Under share:
drwxr-sr-x 2 root Eng-a100 4096 May 15 19:41 applications
drwxr-sr-x 4 root Eng-a100 4096 Apr 25 19:35 apps
drwxr-sr-x 3 root Eng-a100 4096 May 14 05:48 config
drwxr-sr-x 3 root Eng-a100 4096 Apr 14 11:48 mimelnk

Under applications:
-rw-rw-r-- 1 root Eng-a100 908 May 13 22:36 openoffice.org-calc.desktop
-rw-rw-r-- 1 root Eng-a100 1050 May 13 22:36 openoffice.org-writer.desktop

openoffice.org-writer.desktop has:

[Desktop Entry]
Categories=Office;
Comment=Create and edit text and graphics in letters, reports, documents and Web pages by using Writer.
Exec=ooffice -writer %U
GenericName=Word Processor
Icon=ooo-writer
MimeType=application/vnd.oasis.opendocument.text;application/vnd.oasis.opendocument.text-template;application/vnd.oasis.opendocument.text-web;application/vnd.oasis.opendocument.wordprocessingml.template;application/vnd.ms-word.template.macroenabled.12;application/x-zip
Name=OpenOffice.org Writer
Terminal=false
Type=Application
Version=1.0
X-KDE-Protocols=file,http,smb,ftp,webdav

I checked all the paths including the user's ~/.local directory in case there was a higher priority version of the same file but there is not.

What did I do wrong? Interestingly, I moved rather than copied these files from the one user who was working correctly. They are still working correctly!

If you copy those files into the new users ~/.local does it work correctly?

Yes, and the really strange thing is, after I delete them from the local user and reboot their system, it still works??!!

So what is happening? I assume it is not cache as we rebooted. I've checked file permissions all the way along the path of the KDEDIR entries and they are all readable. I do not know why it does not work from the central location, it works when done locally, then continues to work locally even after deleting the files. Thanks - John

After removing the file locally, please run "kbuildsycoca --noincremental"

Only thing I can think of is that you may need to set "XDG_DATA_DIRS" to all of the paths in $KDEDIRS as well as /usr/share ( except with /share added on the end, ie. /data/.Common/kde3profiles/clientadmins/share )

There must a third piece to make this work. Running kbuildsycoca --noincremental did not remove the options from the user from whom I had removed the .local entries. However, I renamed the .desktop files in /data/.Common/kde3profiles/default/share/applications and the options then disappeared from the user so the central .desktop files are being used.

So it appears the entries in profilerc are necessary to establish the preference order, the .desktop files are necessary to associate the applications with the mime-types, but there is something else which tells Konqueror specifically to list the other applications in the "open with" options. What is that? I grepped the entire .kde/share directory for application/x-zip and found nothing we did not already know about. How does Konqueror populate the "open with" popup menu item? Thanks - John