SoC proposal: shell integration

[Mikołaj Zalewski]

  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