[maemo-developers] Is it possible to make a "well-behaved" pyGame app with maemo-python ?

[From: Aleksandr Koltsoff]

Pierre Amadio opened a bug about this issue already way back:
https://bugs.maemo.org/show_bug.cgi?id=1475

(The bug is still set at "NEW").

Fred Pacquier wrote:
> Eero Tamminen a écrit :
>> So you've now verified that Exec part works, whether it's in
>> .desktop or .service file.  What about the service name,
>> Does the service name in .desktop match the .service file?
>> I don't really know D-BUS, but when looking at the maemoblocks
>> stuff on the device:
>> /usr/share/applications/hildon/maemoblocks.desktop:
>> X-Osso-Service=br.org.indt.maemoblocks.startup
>> /usr/share/dbus-1/services/br.org.maemoblocks.startup.service:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I hope there's a typos in that filename (missing.indt) or I don't 
> understand anything anymore :-)

1) The name of the .desktop file is not important. Task navigator will
scan through the directory (/usr/share/applications/hildon/) whenever
there's a change in that directory and will read through the files (not
sure whether only the new file are all files).

For consistency, using a filename like "programname.desktop" would be
logical (IMO). One menu-entry per application.

2) The contents of .desktop file is important. X-Osso-Service is the
D-Bus well-known name that Task navigator will attempt to activate via
D-Bus daemon.

3) The name of the .service file is not important. The D-Bus bus daemon
will read all files from /usr/share/dbus-1/services whenever that dir
changes (similar to Tn above).

It seems that there are no established conventions in maemo for the
filename here. One sees names which contain the well-known-name
(com.nokia.foo.service) and names which contain the application name
(application.service). Technically the name is NOT significant. I'd
think that using the well-known name as part of the filename
(com.nokia.foo.service) would be more logical here, since a single
application can provide multiple well-known-names (each being described
in a separate service file).

4) The contents of the .service file is important. It tells the bus
daemon which program to run when:
a) Someone will attempt RPC to a well-known name that is not already
registered (program providing that name hasn't been started).
b) The service name in a service file matches the "well-known" name of
the request. In the case of applications started via Tn, this must match
exactly the name given in "X-Osso-Service".

It would be nice to get debugging output from D-Bus daemon in this case
(when it can't find any service file matching an RPC request OR fails to
find the executable listed with Exec, OR fails to start the executable).
Not sure whether dbus-monitor can be used nowadays (4.0) for this. But
some kind of debugging support would be very much useful.

5) Once the daemon will start the Exec program that _should_ provide the
name, the program will need to register that name onto the D-Bus. This
can be done with creating the OSSO context (or by other means, as long
as the correct name will appear on the bus).

So, the above rules pretty much contain everything that needs to be done
in order for the activation to work. The rules are indeed complicated by
the fact that when one uses non-qualified names (names without dots in
them), 2) and 5) will prefix the listed name with "com.nokia.".

For 3rd party applications, you should never use names without dots in
them, to avoid the prefixing. This is unfortunately not explained in any
of the HOWTO/tutorials, but can be "easily" read from LibOSSO source
code. Fixing the documentation comments in LibOSSO to explain the
behaviour wrt names in
http://maemo.org/api_refs/4.0/libosso/group__Init.html#g05d45d1e72c2cd74f665086225141431
would be nice as well. The documentation can now easily be understood to
mean that "com.nokia." is always prefixed, when it fact it's only
prefixed when the 'application' parameter doesn't contain any dots.

Here, debugging support would again be nice, so that one could see:
a) what application is started (Exec) and the commandline (Exec)
b) what name(s) the application will register on the bus
c) whether the application registers any names (this is the case where
the app would eventually be killed).

As for application icons missing from Tn, I think that's a separate issue.

ak.