Bug 81772 - Launching the app specified by Exec= in .directory files when entering a directory
Summary: Launching the app specified by Exec= in .directory files when entering a dire...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-18 00:31 UTC by probono
Modified: 2009-09-16 23:17 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Implementation of the feature (1.48 KB, patch)
2004-09-10 15:38 UTC, David Faure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description probono 2004-05-18 00:31:02 UTC
Version:            (using KDE KDE 3.2.2)
Installed from:    Debian testing/unstable Packages
OS:                Linux

A .desktop file can be used to adjust the appearance of the folder that contains the .desktop file. However, the Exec= entry is ignored. 

The bug is as follows:
Konqueror does not execute the action specified in Exec= inside the .desktop file, but instead it simply opens the folder when the folder is clicked in Konqueror. 

This is bad, because this way one cannot create "folder actions" (as known from Mac OS, where a click on a folder that contains an application does not open the folder but instead opens the application).

I consider this a "bug" rather than "wishlist" because Exec= is specified in the freedesktop.org Desktop Entry Standard (see http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html)
The specification says that the Exec= feature "must" be supported by compliant implementations.
Comment 1 Christian Loose 2004-05-19 10:56:04 UTC
Please re-read the specification. 

The Table "Standard Keys" under the topic "Recognized desktop entry keys" as a column "Type". There are four types of different .desktop files: Application(1), Link(2), FSDevice(3) and Directory(4). The column "Type" specifies for what type of .desktop file this Key is for.

In the row for the Key "Exec=" you will find that it is only for application desktop files (type 1).

So I'm changing this to wish.
Comment 2 probono 2004-05-20 00:03:02 UTC
Thanks for pointing this out. Still, having Exec= work in .desktop files of type "Directory(4)" would be very useful (e. g. for creating self-contained  AppDirs that launch an application if clicked), so I still vote for it. 

(http://freshmeat.net/articles/view/247/ explains why AppDirs are useful, and on http://klik.berlios.de/architecture/ I explain an implementation which I am currently working on and would need Exec= for.)
Comment 3 probono 2004-06-08 12:54:59 UTC
I did an error in describing: Instead of ".desktop" it should read ".directory" above.

See for example, the (imaginary) file $HOME/kommander/.directory as follows:

[Desktop Entry]
Encoding=UTF-8
Icon=$HOME/kommander/kommander.png
Exec=$HOME/kommander/kommander <-- this should get executed instead of opening the directory in Konqueror

This way, the Kommander AppDir would have the kommander icon and would execute kommander when clicked (like .app bundles do on the Mac). 

(I am working on "useraland-apt" which will be the backend to easily create AppDirs from debian packages - so this is really needed, not just a vague idea)
Comment 4 probono 2004-07-31 00:43:15 UTC
Apple describes it this way: 

"A bundle is basically a directory that contains an application. Unlike normal folders, however, it appears to the user like an ordinary file. The user can double-click a bundle, and the application will launch. Since the bundle is really a directory, it can contain all the support files that are needed for the application."

http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/distributing/chapter_9_section_2.html

It would be great to have the functionality described in KDE.
Comment 5 David Faure 2004-09-10 15:34:07 UTC
This sounds interesting... And it's not too hard to do - see attached patch.
I chose to do it in lmbClicked() instead of KonqMainWindow::openURL() so that it's still possible to type the URL of the directory in the location bar and open the directory as usual.
Comment 6 David Faure 2004-09-10 15:38:17 UTC
Created attachment 7482 [details]
Implementation of the feature

Please test if that's the way you wanted it.
Comment 7 Maksim Orlovich 2004-09-10 15:39:45 UTC
This sounds like a security risk to me, though.  What happens when someone drops a .directory file in /tmp?
Comment 8 David Faure 2004-09-10 18:11:20 UTC
> This sounds like a security risk to me, though.  What happens when someone drops a .directory file in /tmp?
Excellent point. It sounded like a security problem to me too, but I couldn't pinpoint a bad case.
Your example is a perfect one :/

The question becomes: how is this handled on MacOSX, e.g. what do they do differently
that prevents this from happening?

Comment 9 Elektro Schock 2004-12-11 17:45:07 UTC
Afaik there is an execution rights system for directories on Unix. So I do not understand the problem.
Comment 10 David Faure 2004-12-11 23:21:43 UTC
The +x right for directories means "enter directory", not "execute".

Comment 11 probono 2005-03-05 19:33:33 UTC
Here is the solution, Apple does it like this: Exec= is only executed if the name of the directory ends in .app - otherwise Exec= is ignored. (Apple doesn't display the .app suffix in their file manager, so that the end user doesn't notice it.) This imho resolves the security issue described above.
Comment 12 Sheldon 2005-09-18 02:07:48 UTC
David, what is rhe feasibility of adding the check that probono suggest? Only execute on directories ending in .app ?
Comment 13 probono 2006-04-16 11:27:04 UTC
Can we use the .app solution?
Comment 14 Martin Kunev 2008-11-28 14:21:19 UTC
I don't think it is secure to add such a feature. Maybe the apple way is safer but I still don't think it is a good idea.
Comment 15 FiNeX 2009-09-16 23:17:17 UTC
All reports about file management mode reported against KDE 3 (konqueror) has been closed: konqueror in KDE 3 is no more developed and mantained. All bugs and wishes which could be interesting for Dolphin in KDE 4 (the new KDE file manager) has been collected into a specific list.

Please try the new file manager before request new features and report bugs.

Before submitting new reports check carefully the already opened KDE/Dolphin reports in order not to add duplicates.

Many thanks.