Re: Setting working directories for applications?
On Tue, Apr 14, 2009 at 8:02 AM, Damjan Jovanovic wrote: > Do our .desktop files even work on Mac? Out of curiousity, do we have testcases for this stuff? E.g., will it show up as failing on platforms that don't support it on http://test.winehq.org/ ? -- -Austin
Re: Setting working directories for applications?
Damjan Jovanovic wrote on April 14th: > >On Sun, Apr 12, 2009 at 8:29 AM, Igor Tarasov wrote: > >Do our .desktop files even work on Mac? > I don't think the Aqua specification allows for .desktop files, but .lnk files are connected to the Winehelper application and they do work. If the .desktop files require a specific launcher, it may be possible to get them to work on a Mac. James McKenzie
Re: Setting working directories for applications?
On Sun, Apr 12, 2009 at 8:29 AM, Igor Tarasov wrote:
> Hello.
>
> This might be a known issue, but anyway: Some windows applications
> need that shortcut (launcher) have working directory set, and that
> working directory sometimes different from where the .exe is located.
>
> In Linux, with gnome and kde it is not a big problem, since .desktop
> launchers in these DE support Path attribute. But this becomes a
> problem with systems that don't support this out of box.
>
> As good as I am aware, XFCE have this problem - it's launchers ignore
> path attribute. Also, AFAIK, there are similar problems with mac
> version. There might be problems in other desctop enviroments, but I
> am not aware of these.
The Path attribute is definitely NOT optional. Its presence in a
.desktop file is optional ("If a key is OPTIONAL it may or may not be
present in the file" -- the spec), but a desktop must never ignore it
if it is given.
> Is there anything that could be done in this area?
You should file a bug with XFCE and any other buggy desktops.
Do our .desktop files even work on Mac?
>
> --
> Igor
>
>
>
Damjan
Re: Setting working directories for applications?
Well, I've already have looked into start.exe, and it does not provide functionality I need. Look: we have some program, prog.exe It is located it ~/.wine/drive_c/foo/ . But it needs it's working dir to be set to ~/.wine/drive_c/foo/bar. So, from terminal you can launch it this way: cd ~/.wine/drive_c/foo/bar wine ../prog.exe Start.exe won't help here, as I don't see any path-related options there. Using: wine start 'c:\windows\Start Menu\My App\App.lnk' ususally does the trick. However, this can also be hard for a novice to guess. Mikołaj Zalewski
Re: Setting working directories for applications?
> Currently wine can't launch .lnk files. I was wrong: wine start /path/to/lnk.lnk -- Igor
Re: Setting working directories for applications?
2009/4/12 James McKenzie : > The problem is that you are technically working in Windows and the > working directory may need to be set in the registry. Why? And where? Working directory in cases I've seen is specified in .lnk file. Wikipedia: "Generally the effect of double-clicking a shortcut is intended to be the same as double-clicking the application to which it refers, but Windows shortcuts contain separate properties for the target file and the "Start In" directory. If the latter parameter is not entered, attempting to use the shortcut may generate "missing DLL" errors not present when the application is accessed directly" > Please look at this in a working Windows configuration. I don't have windows box at hand, but I'll check that as soon as I can. In my opinion, there are two ways to solve this: 1) depend on DE, creating .desktop or alias or whatever, and hope that it would work. And we know that at least in XFCE it won't, and since Path parameter is optional in freedesktop specification, there might be more DEs where we'll have this problem. 2) create some kind of internal functionality so that wine could reproduce .lnk behavior without need in relying on DE. For instance, wine could associate itself with .lnk files (don't know why, but I don't like this idea). Or we could save all lnk files somewhere and have some tiny command like wine /path/to/link.lnk that would read all options from .lnk file and change working dir/do whatever required and launch the application. Currently wine can't launch .lnk files. Another way to do this is to add optional parameter to wine, say "--workdir", and wine would convert lnk to .desktop, but save StartIn parameter not in Path, but in command line: wine --workdir /work/dir /path/to/exe -- Igor
Re: Setting working directories for applications?
Igor Tarasov wrote: > Hi Jeff > > >> There is Wine's start.exe which takes a /Unix option to start the >> supplied file in unix path form, which both sets the working directory >> and provides the commandline double quoting quirk which Windows >> Explorer does. So, instead of cd ~/.wine/drive_c/foo && wine bar.exe, >> you can wine start /Unix ~/.wine/drive_c/foo/bar.exe >> > > Well, I've already have looked into start.exe, and it does not provide > functionality I need. > > Look: we have some program, prog.exe It is located it > ~/.wine/drive_c/foo/ . But it needs it's working dir to be set to > ~/.wine/drive_c/foo/bar. So, from terminal you can launch it this way: > > cd ~/.wine/drive_c/foo/bar > wine ../prog.exe > > Start.exe won't help here, as I don't see any path-related options there. > > When installing such application, wine woul convert .lnk into .desktop > that look like this (irrelevant options skipped): > > [Desktop Entry] > Name=Da Prog > Exec[$e]=env WINEPREFIX="/home/user/.wine-wt" wine "C:\\foo\\prog.exe" > Path[$e]=$HOME/.wine/dosdevices/c:/foo/bar > > XFCE ignores Path attribute, and prog.exe won't launch or would > complain it can't find some files and needs to be reinstalled. > > Mac also have some problems with this. > > BTW, according to freedesktop specification Path attribute is optional. > http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html > > The problem is that you are technically working in Windows and the working directory may need to be set in the registry. Please look at this in a working Windows configuration. I have found in these cases that using regedit and duplicating the setup does tend to work. And the fact that you are using a Mac does not have anything to do with this situation, it is a 'broken' feature of Windows that Wine has to reproduce properly. James McKenzie
Re: Setting working directories for applications?
On Sun, 12 Apr 2009 11:29:06 +0500, you wrote: >Currently the only way to lauch such applications is either to use >terminal and cd to working directory and then run application, or >create custom bash launcher, Third option: In the existing launcher instead of: wine "X:\pathto\program.exe" change to: sh -c 'cd somepath && wine "X:\pathto\program.exe"' Works here using Gnome. Not very user-friendly either perhaps. Rein.
Re: Setting working directories for applications?
Hi Jeff > There is Wine's start.exe which takes a /Unix option to start the > supplied file in unix path form, which both sets the working directory > and provides the commandline double quoting quirk which Windows > Explorer does. So, instead of cd ~/.wine/drive_c/foo && wine bar.exe, > you can wine start /Unix ~/.wine/drive_c/foo/bar.exe Well, I've already have looked into start.exe, and it does not provide functionality I need. Look: we have some program, prog.exe It is located it ~/.wine/drive_c/foo/ . But it needs it's working dir to be set to ~/.wine/drive_c/foo/bar. So, from terminal you can launch it this way: cd ~/.wine/drive_c/foo/bar wine ../prog.exe Start.exe won't help here, as I don't see any path-related options there. When installing such application, wine woul convert .lnk into .desktop that look like this (irrelevant options skipped): [Desktop Entry] Name=Da Prog Exec[$e]=env WINEPREFIX="/home/user/.wine-wt" wine "C:\\foo\\prog.exe" Path[$e]=$HOME/.wine/dosdevices/c:/foo/bar XFCE ignores Path attribute, and prog.exe won't launch or would complain it can't find some files and needs to be reinstalled. Mac also have some problems with this. BTW, according to freedesktop specification Path attribute is optional. http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html -- Igor
Re: Setting working directories for applications?
On Sun, Apr 12, 2009 at 4:29 PM, Igor Tarasov wrote: > Hello. > > This might be a known issue, but anyway: Some windows applications > need that shortcut (launcher) have working directory set, and that > working directory sometimes different from where the .exe is located. > > In Linux, with gnome and kde it is not a big problem, since .desktop > launchers in these DE support Path attribute. But this becomes a > problem with systems that don't support this out of box. > > As good as I am aware, XFCE have this problem - it's launchers ignore > path attribute. Also, AFAIK, there are similar problems with mac > version. There might be problems in other desctop enviroments, but I > am not aware of these. > > Currently the only way to lauch such applications is either to use > terminal and cd to working directory and then run application, or > create custom bash launcher, which is too complicated for not > experienced users (I mean not to reproduce it step-by-step, but to > solve it by themselves). > > Is there anything that could be done in this area? > > -- > Igor > > > Hi Igor There is Wine's start.exe which takes a /Unix option to start the supplied file in unix path form, which both sets the working directory and provides the commandline double quoting quirk which Windows Explorer does. So, instead of cd ~/.wine/drive_c/foo && wine bar.exe, you can wine start /Unix ~/.wine/drive_c/foo/bar.exe I think this is already used as part of DE, see tools/wine.desktop, perhaps it would be a good idea to fix whatever is broken in XFCE and others. Jeff
Setting working directories for applications?
Hello. This might be a known issue, but anyway: Some windows applications need that shortcut (launcher) have working directory set, and that working directory sometimes different from where the .exe is located. In Linux, with gnome and kde it is not a big problem, since .desktop launchers in these DE support Path attribute. But this becomes a problem with systems that don't support this out of box. As good as I am aware, XFCE have this problem - it's launchers ignore path attribute. Also, AFAIK, there are similar problems with mac version. There might be problems in other desctop enviroments, but I am not aware of these. Currently the only way to lauch such applications is either to use terminal and cd to working directory and then run application, or create custom bash launcher, which is too complicated for not experienced users (I mean not to reproduce it step-by-step, but to solve it by themselves). Is there anything that could be done in this area? -- Igor
