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
- SoC proposal: shell integration Mikołaj Zalewski
-
