Hi Lei,
I think a new file for user dir look up in the shell32 is of no use. Rather than we can add it to the xdg.c and xdg.h, as it contains the generic xdg code for shell32. Its like having all xdg specific code at one place. This is my personal opinion about those patches.
Thanks, VJ
On Nov 26, 2007 4:49 PM, Vijay Kiran Kamuju infyquest@gmail.com wrote:
Hi Lei,
I think a new file for user dir look up in the shell32 is of no use. Rather than we can add it to the xdg.c and xdg.h, as it contains the generic xdg code for shell32. Its like having all xdg specific code at one place. This is my personal opinion about those patches.
Thanks, VJ
I was not sure if was alright to mix code with different licenses in the same file. I looked around and found that include/wine/wined3d_gl.h has both LGPL Wine code as well as MIT licensed code from the Mesa project. Based on that, I guess it's ok to do, so I will send out another patch.
- Lei
"Lei Zhang" thestig@google.com writes:
I was not sure if was alright to mix code with different licenses in the same file. I looked around and found that include/wine/wined3d_gl.h has both LGPL Wine code as well as MIT licensed code from the Mesa project. Based on that, I guess it's ok to do, so I will send out another patch.
It's OK to do, but I don't think you want to copy the code as is, you should write your own version that parses the file only once and handles variables as they are found. Also these variables should take priority over the default heuristics, and you most likely want to handle the desktop dir the same way.
On Wed, 28 Nov 2007, Alexandre Julliard wrote: [...]
Also these variables should take priority over the default heuristics, and you most likely want to handle the desktop dir the same way.
I'm not sure we want to handle the desktop directory the same way. It's really a special case because applications often put their 'icons' on the desktop. So if the Windows desktop is just a symbolic link to the Unix one, the user will end up with a lot of 'xxx.lnk' files on his desktop. In particular these files will show the wrong icon: they will have the icon associated with 'lnk' files, instead of the one of the application they are supposed to start.
So I think it's best to keep the Windows desktop separate from the Unix one, and let winemenubuilder put 'xxx.desktop' files on the Unix desktop when appropriate.
Francois Gouget fgouget@free.fr writes:
On Wed, 28 Nov 2007, Alexandre Julliard wrote: [...]
Also these variables should take priority over the default heuristics, and you most likely want to handle the desktop dir the same way.
I'm not sure we want to handle the desktop directory the same way. It's really a special case because applications often put their 'icons' on the desktop. So if the Windows desktop is just a symbolic link to the Unix one, the user will end up with a lot of 'xxx.lnk' files on his desktop. In particular these files will show the wrong icon: they will have the icon associated with 'lnk' files, instead of the one of the application they are supposed to start.
So I think it's best to keep the Windows desktop separate from the Unix one, and let winemenubuilder put 'xxx.desktop' files on the Unix desktop when appropriate.
You are right, that one doesn't need to be changed in shell32, but we have to fix winemenubuilder (or rather wineshelllink) to also take the xdg user dirs config into account for the desktop.
On Friday 30 November 2007 03:35:14 am Francois Gouget wrote:
I'm not sure we want to handle the desktop directory the same way. It's really a special case because applications often put their 'icons' on the desktop. So if the Windows desktop is just a symbolic link to the Unix one, the user will end up with a lot of 'xxx.lnk' files on his desktop. In particular these files will show the wrong icon: they will have the icon associated with 'lnk' files, instead of the one of the application they are supposed to start.
Just to note, Wine already does this. The desktop directory is linked to ~/Desktop by default, which is the X desktop directory for most systems. You also should take into account that apps will sometimes place non-lnk files onto the desktop that the user may expect to see (extracted files, downloaded files, readme's, etc).
I'm not sure we want to handle the desktop directory the same way. It's really a special case because applications often put their 'icons' on the desktop. So if the Windows desktop is just a symbolic link to the Unix one, the user will end up with a lot of 'xxx.lnk' files on his desktop. In particular these files will show the wrong icon: they will have the icon associated with 'lnk' files, instead of the one of the application they are supposed to start.
While this is annoying, I find it confusing to go to the "Desktop" directory and not find the files on my desktop there. I prefer having the two desktops the same, and just delete the .lnk files myself.
--Juan
On Fri, 30 Nov 2007, Juan Lang wrote: [...]
While this is annoying, I find it confusing to go to the "Desktop" directory and not find the files on my desktop there. I prefer having the two desktops the same, and just delete the .lnk files myself.
That's ok only because you don't care about the Windows desktop shortcuts...
That's ok only because you don't care about the Windows desktop shortcuts...
Right, I know. My point is, there's no one-size-fits-all policy that's clearly better than any other, at least that I've seen. --Juan
On Fri, 2007-11-30 at 18:45 +0100, Francois Gouget wrote:
That's ok only because you don't care about the Windows desktop shortcuts...
I guess the preferred solution would be to teach GNOME & KDE about .lnk files.
On 30.11.2007 18:50, Dimi Paun wrote:
I guess the preferred solution would be to teach GNOME & KDE about .lnk files.
Or write .desktop files to the Desktop dir.
-f.r.
On Nov 30, 2007 3:50 PM, Frank Richter frank.richter@gmail.com wrote:
On 30.11.2007 18:50, Dimi Paun wrote:
I guess the preferred solution would be to teach GNOME & KDE about .lnk files.
Or write .desktop files to the Desktop dir.
I agree with Juan having multiple "Desktop" directories does not work and it will confuse users. Wine already has enough places were we do that and we should not add even more.
I think teaching them about .lnk files is a better solution. It should not be to hard to have a mime type of *.lnk that invokes Wine and passes the shortcut to the link processor. Really all GNOME & KDE need to do with *.lnk files is have the ability to follow a small part of them to the binary in question and load the Icon data from the resource section. The rest can be off loaded to Wine when a user actually clicks one.
On Sat, 1 Dec 2007, Steven Edwards wrote: [...]
I think teaching them about .lnk files is a better solution. It should not be to hard to have a mime type of *.lnk that invokes Wine and passes the shortcut to the link processor. Really all GNOME & KDE need to do with *.lnk files is have the ability to follow a small part of them to the binary in question and load the Icon data from the resource section.
Great. Now KDE and Gnome will have a PE loader and windows resource parser. Plus when the .lnk points to a document they may have to load the Windows registry to see what icon Windows associated with that document, especially if that document type is not present in the Gnome/KDE MIME database.
Plus, how do you know where 'c:\Program Files\Foo\Bar.exe' is?
[...]
I agree with Juan having multiple "Desktop" directories does not work and it will confuse users. Wine already has enough places were we do that and we should not add even more.
What Wine could do is try to sync the Unix and Windows desktops with FAM magic, all while not replicating the .lnk files to the Unix desktop.
On Dec 1, 2007 8:08 PM, Francois Gouget fgouget@free.fr wrote:
Great. Now KDE and Gnome will have a PE loader and windows resource parser. Plus when the .lnk points to a document they may have to load the Windows registry to see what icon Windows associated with that document, especially if that document type is not present in the Gnome/KDE MIME database.
As apple has show recently, having a minimal PE loader and resource parser does not take a lot of code but we really don't even need that...
See if my logic makes sense for how this would work. I don't understand why the document type would not be registered in the MIME database. I assume that the Windows association information would be synced everytime the user installs an application and winemenubuilder is called. 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 actually just be resident in memory of the WM process.
Plus, how do you know where 'c:\Program Files\Foo\Bar.exe' is?
What this means is that on logon or logoff the WM would call our function and generate these fake Shortcuts for the *.lnk files by running a copy of winepath after calling the Wine shelllink processor. 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.
What Wine could do is try to sync the Unix and Windows desktops with FAM magic, all while not replicating the .lnk files to the Unix desktop.
Yes I am talking about using something like FAM but having it look for *.lnk changes on the users Linux desktop. Evertime a FAM event occors such as an install of a Windows application with a desktop shelllink, the array containing the "fake" shortcuts in the WM is updated. When the user logs off, this data is lost. The WM gets to keep the Windows and Linux Desktop's in sync without having to actually mess with generating new shortcuts and or confusing the user by having multiple directories.
Thanks Steven
On Sat, 1 Dec 2007, Steven Edwards wrote: [...]
What this means is that on logon or logoff the WM would call our function and generate these fake Shortcuts for the *.lnk files by running a copy of winepath after calling the Wine shelllink processor. 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.
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?
What Wine could do is try to sync the Unix and Windows desktops with FAM magic, all while not replicating the .lnk files to the Unix desktop.
Yes I am talking about using something like FAM but having it look for *.lnk changes on the users Linux desktop. Evertime a FAM event occors such as an install of a Windows application with a desktop shelllink, the array containing the "fake" shortcuts in the WM is updated. When the user logs off, this data is lost. The WM gets to keep the Windows and Linux Desktop's in sync without having to actually mess with generating new shortcuts and or confusing the user by having multiple directories.
Well, that sounds like just having Gnome/KDE (!=WM) know how to interpret .lnk files. No specific FAM here beyond what they already do.
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
On 01.12.2007 22:05, Steven Edwards wrote:
I think teaching them about .lnk files is a better solution. It should not be to hard to have a mime type of *.lnk that invokes Wine and passes the shortcut to the link processor. Really all GNOME & KDE need to do with *.lnk files is have the ability to follow a small part of them to the binary in question and load the Icon data from the resource section. The rest can be off loaded to Wine when a user actually clicks one.
One idea I had earlier is to actually store .desktop file data in files ending in .lnk. At least gnome didn't care about the extension (didn't try with KDE due not having it installed). So the "shell links" would show up as proper icons on the desktop. Also, applications would see files with a suffix of '.lnk' so e.g. uninstallers would work correctly when directly deleting link files.
Of course it's a bit of a hack. A technical issue is that the "original" .lnk would have to be preserved somewhere to make sure all attributes can be restored without loss. When the shell is used to access the links, this hiding is not a problem. However, when an application would access the .lnk directly, it'd see a .desktop file. (Don't know how common that is.) Also, since applications could copy/delete a link file directly, some process would have to monitor the Desktop dir and ensure that .lnks are turned to .desktops and that any possibly necessary cleanup of the shadowed original data is done when the .lnk is removed.
-f.r.
-
Alexandre Julliard -
Chris Robinson -
Dimi Paun -
Francois Gouget -
Frank Richter -
Juan Lang -
Lei Zhang -
Steven Edwards -
Vijay Kiran Kamuju