SoC proposal: shell integration
segin2005 at gmail.com
Sun May 7 12:30:20 CDT 2006
Mikołaj Zalewski wrote:
> I've had an idea for a SoC project and filled the application. In a
> comment I was advised to discuss it on wine-devel.
> The idea is to integrate the wine shell32 with the Linux desktops. The
> main problem is of course that there are many desktop environments and
> only some things are standardized by freedesktop.org. Even if all is
> standardised the wine's shell32 might be used on other platforms like
> MacOS X which, I guess, doesn't comply to freedesktop.org. That's why I
> think the implementation should allow many implementations of e.g. the
> trash or MIME database through e.g. COM interfaces. The actual
> implementation used will be configured by winecfg/registry or (if I will
> a way to implement it) autodetected.
> There would be one generic library (e.g. shell32_unix) implementing
> mainly the freedesktop standards with no dependencies on desktop
> environments (DE) libraries. If this generic code would integrate badly
> with a DE then a specific implementation would be provided by specific
> libraries (e.g. shell32_gnome, shell32_kde) that could link to the DE
> libraries. Of course if there are no libraries for a specific DE on the
> host system then the appropriate shell32_* isn't built. I would focus on
> recent version of KDE and Gnome and I thought of implementing:
> - The Trash. The freedesktop has a nice standard. It is a draft but it
> seems KDE from version 3.4 is already using it so wine would integrate
> with them. Gnome is using another Trash format but if that would be a
> big problem I could provide an implementation in shell32_gnome through
> the Gnome libs. The shell32 would contain a stub implementation of the
> Trash that would say no trash is available - so that shell32 could work
> even if the shell32_unix is not available.
> - The Start Menu. This is currently handled by wineshelllink but if we'd
> like to implement file associations we might need more control over it.
> Creating the 'app.desktop' file is easy. A bit harder is to know where
> to create it. The freedesktop standard specifies a standard place for
> the file. The older version of KDE and Gnome used different directories
> (usually ~/.kde/share/applnk or ~/.gnome/apps) but their shell32_*
> libraries could check the version of the DE and if it is old store the
> app.desktop in the DE private directory obtained by a DE library call.
> There could be a problem with detecting the Windows Start Menu changes.
> The links creation can be trapped in IShellLink like it is currently
> done but traping link removal can't be done that way as it is done with
> filesystem calls bypassing the shell32. We may need to put a filesystem
> change notify on the start menu directory and start a synchronization
> program if a change is detected.
> - The file associations. This might be the hardest part. If we detect a
> change to the Windows associations (here again we might need to put a
> change notify on HKEY_CLASSES_ROOT) we should get the class MIME type
> from the registry. If there is no we search the Linux MIME database for
> this extension. If none was found we can make a dummy one e.g.
> applicaton/x-wineapp.extension.xxx. If the found/created MIME type is
> not in the Linux database we should register it. The next step is to
> check if this application has a menu item. If there is no we should
> create a hidden one. Once we have the menu 'app.desktop' file we add the
> line that it handles the specified MIME type. (there are three MIME
> databases I think we should care about - the freedesktop /usr/share/mime
> the KDE /usr/share/mimelnk and maybe the old Gnome /usr/share/mime-info)
> Where was also a comment that this may be to much for one summer. If
> implementing only a part of this plan is enough then of course I'll agree.
> Mikolaj Zalewski
If this was to be done, there are a few things I suggest:
The config for what integrations (e.g. KDE, FD.org, Flux, GNOME, etc.)
are active will be under the Desktop Integration tab in winecfg. This is
pretty much a "d-uh" type deal.
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?). 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.
The real problem with C++ for kernel modules is: the language just sucks.
-- Linus Torvalds
More information about the wine-devel