Version: (using KDE KDE 3.1.1) Installed from: SuSE RPMs OS: Linux it is not possible to set different file associations in konqueror for web browsing and local file managing. For example, I'd like to open simple text files in the web embedded in the browser (or be asked if the file should be saves to disk), while I'd like them to be opened in kate while in lokal file managing mode.
I also would like to see this, especially as you said about the text files. Its alot better for say a changelog to be displayed in the browser while surfing, but to open up say kate while local file browsing.
Yes, this would be a very nice feature. Here's another example: Quite often, users associate image files to an image browser, such as gqview, which allows to zoom, navigate easily between photos with page-up/down, etc. But when surfing and clicking a link to an image (jpg, png, etc.), I do think most users expect it to open in Konqueror. If I want to open it with something else, then I right-clic on it, etc.
*** This bug has been confirmed by popular vote. ***
Here is the problem they way I see it. By default double clicking on a html file on disk opens it in konqueror for display with khtml. This is what you would expect. But as it happens, sometime you will want to edit a html file in some editor instead of viewing it in konqueror. So you associate the html file with the editor for convinience. This breaks the behaviour in various places. Double clicking on a html file will now open it in the editor instead of in khtml, which is probably not what you expect. What's worse, if you click on a link for example in an email, kde will download the html file (using the IO-slave system) and show it in the editor. This is definitely NOT what you would expect. The workaround is to go into the file association settings and reinstate khtml as the primary application for the file type. This way, html files opens in konqueror when you double click them, and links in emails also open in konqueror when you single click them. The file association for your editor is available through the context menu, which is an acceptable situation. Suggestions or ideas: Hijacking the file association is not user friendly. Introduce some kind of 'prefered application' concept for file associations. If a file type has a prefered application, when you add a new file association, the new association is simply added to the bottom of the list of applications that can open this file type and doesn't override the default setup. Another way to do it, without introducing a new file association concept, could be to make the user decide via some checkbox in the add file association dialog, whether the new app should 'hijack' the file type and become the default application for it. The best way though is, as the title of this bugreport suggests, to make possible to have different associations, depending on what profile is active. That way you can have html files open in kate when you click on them in file manager mode, and open in khtml when you are in browsing mode. I want to point out that I don't necessarily think that this solution rules out using some of my above suggestions also. Ultimately I guess the real point is that if this was to be implemented in a 'optimal way', then the file associations should depend very dynamically on the context you are working in. I realize that this makes it a rather complex problem to solve 'perfectly'. I suggest that one starts with finding a sollutions that prevents the 'prefered association' from being hijacked when a new association is added.
This is where your reason went astray: > But as it happens, sometime you will want to edit a html file in some editor > instead of viewing it in konqueror. So you associate the html file with the > editor for convinience. No, you will right-click and select Open With and then the editor of your choice. If you change the default behaviour, you've changed the *default* behaviour. It means you *want* it to open in the editor if you double-click on it. It is the *expected* behaviour. KDE doesn't know the difference: all its told is that you want to open this HTML file. So it opens what you configured it to use. And that's your editor.
Yeah yeah sure, I understand what you are saying. The problem is that the *expected* behaviour, as you put it, has some unexpected consequences. :)
To solve this issue, we could associate an application not to a file type, but to a file type PLUS a protocol. Examples: file:// + HTML => my HTML editor http:// + HTML => konqueror email:// + HTML => konqueror file:// + JPG => my favorite image viewer http:// + JPG => Konqueror etc. Is it possible?