[Logicaldesktop-general] Some reflections

[Maurizio C. <seg...@ti...>]

=46rom the TODO file:

Using .desktop files
=2D-------------------

 With the library "kio.KConfig", we can enumerate the installed
 programs, and read their name, icon, executable file, and the mime
 types managed by each program.

 Additionally, with the library "kdecore.KDesktopFile", we can parse
 .desktop files in kde/share/apps/konqueror/servicemenus, and discover
 the additional actions supported by the programs --- the actions that
 appear in konqueror "Actions" menu (e.g. "create data cd with k3b").

 Now, how can LD use those informations? First of all, it is important
 to understand that LD must also display informations (icon, verbs...)
 about programs that are NOT installed! So it cannot rely on .desktop
 files completely, because .desktop files are only available for
 installed programs. LD still needs an internal db of programs and
 their capabilities.

 Does this mean .desktop files are completely useless for LD? This
 would only be true if adding support for a program did not cost us
 anything. But it does cost, so our program database is neither
 complete nor accurate.

 1. there are still many programs LD doesn't know;

 2. thare are many programs for which LD has wrong informations
    (e.g. it does not know all the mimetypes they manage; it has an old
    icon; it does not know all the actions they support).

 3. there are many unimplemented verbs.

 The idea is to use the .desktop files where present, to solve those
 problems:

  1. add some kind of basic support for programs that are installed
     but unknown to LD;

  2. refine informations for programs that are installed and known to
     LD;

  3. automatically read the implementation for verbs from the .desktop
     files.

Unfortunately, there are many subtle problems with these points.

Problem: UNKOWN PROGRAMS CANNOT OPEN KNOWN FILES. Suppose in LD there
is a verb "play audio", which requires an mp3 or an ogg. Suppose LD
knows the programs "xmms" and "totem" that support that verb. Suppose
now LD finds a new program "kaffeine", whose .desktop file says it can
open mp3 and ogg files, but specifies no action. LD knows nothing
about what the program will do with the mp3 file: will it play them?
Will it encode/decode them?  So LD cannot add kaffeine to the programs
that support "play audio". And it cannot simply add a generic verb
"open with", because it would conflict with "play audio": suppose the
user selects an mp3. He sees the verbs "play audio" and "open with",
which is too ugly.  Conclusion: LD cannot allow unknown programs to
open KNOWN files. --------------- Even if the program declares an
action, things don't change: suppose the same as before, but this time
kaffeine has a .desktop file that not only specifies the mimetypes mp3
and ogg, but also declares an action "play sound" --- and says the
action can be applied to mp3 files. Unfortunately LD cannot understand
that the meaning of the actions is the same as "play audio", so it
cannot simply add kaffeine to the programs that support "Play audio".
LD cannot add a new action "play sound" either: this would cause the
same problem as before: suppose the user selects an mp3: then he will
see two verbs: "Play audio" and "Play sound". This must not
happen. --------------------What about unknown programs that manage
files of any type? Like krename? Or any directory, like kdirstat? we
can't accept these programs either. Suppose we find a program that can
manage any file, like krename. LD cannot tell that krename renames
files: it can only add a verb "open with krename" or whatever action
krename declares. But this is not enough: if the user clicks "rename
file", krename should appear in the list, but it does not. This cannot
happen.


Problem: UNKNOWN PROGRAMS THAT DON'T MANAGE FILES CANNOT BE
ADDED. Suppose LD finds an unknown program called "switcher" that
actually turns off your computer. Even if "switcher" supplies an
action "turn off computer", LD cannot tell what switcher does. So it
cannot add it to the right verb ---which is "Power off". If LD simply
added the verb "Switch off computer", and the user selected "power
off", he would not see switcher, which is an error.


Problem. DESKTOP FILES CANNOT BE USED TO ASSOCIATE KNOWN MIMETYPES TO
A KNOWN PROGRAM. Suppose LD thinks that xmms can manage only mp3
files, but in the .desktop file for xmms it's written that xmms can
manage ogms too. Suppose ogms are known by LD (i.e. some verb requires
ogm). Then, unfortunately, ogms cannot be added to the verb "play
audio", even xmms supports that verb, because LD does not know WHAT
xmms can do to ogm files; in theory it could even do something that
completely different from "play"!

Example. UNKNOWN PROGRAMS THAT MANAGE UNKNOWN FILES CAN BE ADDED. If
there is a program (oowriter) that manages an unknown file (sxw), LD
can add a verb "open sxw" and associate oowriter (and any other
program that manages sxw) to it. There is no conflict with that. Also
it oowriter manages some known files, it is no problem either:
oowriter will only be usable to open sxw files. You can't use it to
open known files, for reasons explained earlier.

Example. DESKTOP FILES CAN BE USED TO ASSOCIATE UNKNOWN MIMETYPES TO A
KNOWN PROGRAM. Suppose LD knows oowriter, but only knows it can manage
sxw files. LD doesn't know oowriter can manage DOC files. In that
case, if DOC is an unknown file, LD can create a verb "open
DOC". Unfortunately, if DOC is known (i.e. there is already a verb
that requires DOC files), nothing can be done, for reasons explained
earlier.

Example. DESKTOP FILES ALLOW US NOT TO WRITE THE SEMANTICS
ANYMORE. For example, now LD has a semantics for "Burn data cd" has an
internal switch that does "k3b --datacd <files>" or "xcdroast
=2D-data-cd <files>" depending on the program chosen by the user. This
will not be necessary anymore. All the LD programmer must do is to
associate the LD verb "Burn data CD" with the actions {"Create data cd
with k3b", "create cd with xcdroast"}, whose commandline is specified
in .desktop files for k3b and xcdroast.