SoC proposal: shell integration

[Segin]

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.

Sounds good?

-- 
The real problem with C++ for kernel modules is: the language just sucks.
	-- Linus Torvalds