Segin wrote:
If this was to be done, there are a few things I suggest:
First should be everything that Freedesktop.org has laid out, and
nothing more. That does into the FD.org integration code. For a lot of
this to work, Wine may have to be ran as a system service (is that
even a good idea?).
I don't know what you mean by a system service but there will be no
need for a new kind of processes. The Trash code can run in the client's
process. Checking the Start Menu and HKEY_CLASSES_ROOT needs to be done
in a separate process/thread and but as I see the wine explorer is used
for such tasks. No privileges are required as the code can create the
menu items/MIME entries in the home directory (and it is probably the
desired way as by default wine is installed in each home directory for
the current user only).
Each part of the integration profiles that is Wine-specific code
should be done like the audio drivers, a Wine .drv.so or similar.
shellfdorg.drv.so for Freedesktop, shellkde3.drv.so for KDE 3,
shellkde.drv.so for generic KDE (stuff that works on both 3 and 4),
and so on.
I was thinking about COM interfaces. Then the code would be in regular
DLLs with no need for a special infrastructure. The shell32_unix.dll
from my proposal was what you call shellfdorg.drv.so, the
shell32_kde.dll is the shellkde.drv.so etc.
Mikolaj Zalewski
