On Dec 2, 2007 9:16 AM, Francois Gouget fgouget@free.fr wrote:
How does Gnome/KDE know which WINEPREFIX to use for foo.lnk? Why should it be '~/.wine' rather than '~/.wine-steam', '~/.wine-office' or something else?
Maybe rather than storying the information in memory and creating it at DE startup and destroying it at DE exit like I proposed, we should store it all in gconf or something and export functionality from Wine so that GNOME or KDE can know which WINEPREFIX made what changes. Let me extend my plan a bit and see what you think...
A user installs Wine which registers the MIME type of *.lnk with the Desktop Environment. A user starts Wine and installs an application that writes a *.lnk to the Desktop. Our DE Service or exported API then stores the following information from Winemenubuilder in gconf for the target *.lnk
Shortcut Name:
Say you have sol.lnk on the desktop GNOME and KDE should be smart enough to parse sol.lnk and actually display Solitaire or Solitaire (Windows) or something. This "fake" shortcut would not be the filename of course, just the name that it pulls from gconf for that shortcut. I think the *.lnk files contain a longer name describing what they are actually pointing too right?
Shortcut Target Support:
The results of winepath would translate 'c:\Program Files\Foo\Bar.exe' in to '~/.wine/dosdevices/c:/Program Files/Foo/Bar.exe and pass that to the array in memory containing the "fake" shortcuts.
WINEPREFIX: Lets say a user is running the steam installer from a WINEPREFIX=~/.wine-steam and it writes *.lnk files to the desktop. winemenubuilder stores a reference to this in gconf which overrides the MIME type handler by setting this varible before starting Wine and processing the *.lnk file. Maybe explorer or winemenubuilder export this information using dbus? I don't know all the low level details.
Associations: Again I assume this would be winemenubuilders job to keep in sync everytime it is called by an installer.
I think we can extend such a framework to cover every corner case if we can make use of gconf, dbus, the mime handler. I don't know what we would use in the KDE case instead of gconf so I will leave that up to someone else to make a suggestion. I do think this is an important issue as multiple Desktop folders confuse me! I can imagine how some who has never used Wine has felt. Also a final thought....we could always make another code path so the current support for private Wine Desktop directories still exist but the framework I've described is opted IN via a registry key that could be set via winecfg.
Thanks