27 Nov
2007
27 Nov
'07
12:49 a.m.
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
28 Nov
28 Nov
7:49 p.m.
On Nov 26, 2007 4:49 PM, Vijay Kiran Kamuju <infyquest(a)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
10:31 p.m.
"Lei Zhang" <thestig(a)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.
--
Alexandre Julliard
julliard(a)winehq.org
30 Nov
30 Nov
11:35 a.m.
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(a)free.fr> http://fgouget.free.fr/
Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
11:42 a.m.
Francois Gouget <fgouget(a)free.fr> writes:
On Wed, 28 Nov 2007, Alexandre Julliard wrote:
[...]
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.
--
Alexandre Julliard
julliard(a)winehq.org
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. 
11:58 a.m.
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).
3:27 p.m.
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
5:45 p.m.
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...
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt
IP over Avian Carriers with Quality of Service
1 Dec
1 Dec
9:05 p.m.
On Nov 30, 2007 3:50 PM, Frank Richter <frank.richter(a)gmail.com> wrote:
On 30.11.2007 18:50, Dimi Paun wrote:
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.
--
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
I guess the preferred solution would be to teach
GNOME & KDE
about .lnk files.
Or write .desktop files to the Desktop dir.
2 Dec
2 Dec
1:08 a.m.
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.
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Indifference will certainly be the downfall of mankind, but who cares?
3:26 a.m.
On Dec 1, 2007 8:08 PM, Francois Gouget <fgouget(a)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
--
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
2:16 p.m.
On Sat, 1 Dec 2007, Steven Edwards wrote:
[...]
Well, that sounds like just having Gnome/KDE (!=WM) know how to
interpret .lnk files. No specific FAM here beyond what they already do.
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
It really galls me that most of the computer power in the world
is wasted on screen savers.
Chris Caldwell from the GIMPS project
http://www.mersenne.org/prime.htm
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.
4:22 p.m.
On Dec 2, 2007 9:16 AM, Francois Gouget <fgouget(a)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
3 Dec
3 Dec
8:25 a.m.
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.
6013
days inactive
6019
days old
16 comments
9 participants
participants (9)
-
Alexandre Julliard -
Chris Robinson -
Dimi Paun -
Francois Gouget -
Frank Richter -
Juan Lang -
Lei Zhang -
Steven Edwards -
Vijay Kiran Kamuju