[maemo-users] [maemo-users] Re: Re: Unzip - GUI or linked through File Manager?

From: Danny Milosavljevic danny_milo at yahoo.com
Date: Wed Feb 7 23:49:10 EET 2007

On Wed, 07 Feb 2007 14:25:22 -0600, Paul Klapperich wrote:
> Ok, nevermind. I think I mostly understand why now...
> I followed the instructions in the Maemo Developers Tutorial [1] creating a
> .desktop file for unzip and an xml mime-type definition. The downside for
> this is that "unzip" shows up in the application list, but filemanager does
> claim to be "loading unzip." 


> I guess the real downside is that it doesn't unzip :-) 


> Still not sure why you think you need a %f, but this obviously
> isn't as straight forward as it should be. 

Usually, desktop files register an application with the desktop system(s).
This means with everything: the menus, the file manager, the full text search, ... 

In case of the file manager, once the user tries to open a file [1], the file manager is supposed to check the "MimeType" entry of all desktop files[2] and if some application matches[3], then it should parse the "Exec" entry, replace "%f" by the file path (and several others) and then use that command line to create a process...
This is described in detail in Desktop Entry Specification[4].

Maemo extended this is order to cut down on number of process creations (presumably because it got faster that way, I hope, otherwise that would be sick):

The desktop file now can have a "X-Osso-Service" (I think) entry and this specifies the name of a dbus service.
This dbus service must be registered by the application[5] by putting a file into "/usr/share/dbus-1/services/". This file is a configuration that lists the (new) dbus service name and the executable to start when that name is used.

Now when the file manager processes the "file open", it will read that key (I think, never saw the code yet), prepend "com.nokia." (sigh...), then ask dbus for that service.

Dbus will check whether that is running, and if not, start the executable from the service file's "Exec" key.

At this point, it's guaranteed that the application's dbus service is running, and by that, that the application is running.[9]

The file manager sends a dbus message to the application's dbus service.
The application ['s dbus service] enters the callback set by osso_mime_set_cb, gets passed URLs (yeah... URLs) of the files that it's supposed to open[6].

>I'd assume the Filemanager is waiting for a dbus response from the application it just launched, which the commandline app "unzip" just won't do.


For completeness:

> Obviously "%f" would be the filename path, but what would be "calling" this .desktop file? 

In this case, the file manager (maybe via a helper library).

The Desktop Entry Specification[7] says:
>An application is expected to be able to reasonably open files of these types [listed in the MimeType value] using the command listed in the Exec key.

> My experience has been .desktop files either show up on the Gnome desktop on a PC, or in the application list on either a desktop or here on maemo.
> What would tell the .desktop file what to place into %f?

The Desktop Entry Specification[4] says:
>%f    A single file name, even if multiple files are selected. The system reading the desktop entry should recognize that the program in question cannot handle multiple file arguments, and it should should probably spawn and execute multiple copies of a program for each selected file [...]

>> Perhaps the reason for a lack of answer is that nobody understand why  you're trying to do that... 

Maybe :-) we'll see, now that I elaborated here :-)

btw: 350 lines of C and counting... [8]


[1] as opposed to Edit, Print, ... - asked about that too, no answer yet - these are called "Desktop Actions"
[2] just in certain directories, like "/usr/share/applications/"
[3] there is extra confusion about what to do when TWO applications claim to be able to handle it - I've been asking that too, no answer yet - ideally it would pop up a menu and ask
[4] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
[5] or else, osso_initialize fails
[6] or Edit or Print or xxyy or ..., although I don't see how I would know which
[7] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
[8] http://www.scratchpost.org/patches/batch-unzip.c <-- this is NOT finished
[9] If it is not, maemo desktop will just show "Loading..." for some time, then cancels. Or maybe say "Unable to open", who knows.

More information about the maemo-users mailing list