SoC proposal: shell integration
mikolaj at zalewski.pl
Sun May 7 13:13:12 CDT 2006
> 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.
More information about the wine-devel