SoC proposal: shell integration
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
Re: SoC proposal: shell integration
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
Re: SoC proposal: shell integration
Segin wrote: 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. Mikolaj Zalewski
