xdg_user_dirs patches

[Steven Edwards]

On Dec 2, 2007 9:16 AM, Francois Gouget <fgouget at 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
-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo