Printable View
Hi,
When I link an extension to a Windows Program, through Wine, using the item "Open with another application",
I can run the application, and the filename is added as 1st parameter in the command line. Fine.
The problem is that the Windows program expects Windows filename syntax and cannot open the file with it's LINUX filename.
Is there any way to fix this problem ?
Thanks a lot for ideas.
Martin.
As far as I know, the only difference -at practical level- which I can think of right now is that linux is case sensitive AND case recordable, while windows records the case but completely ignores it on command line.Quote:
Originally Posted by martinus
Being that said, the difference when using wine is zero, because wine will understand the file name correctly just like windows does. For example, if the file is called "fOObAr.EXe", wine will run is right even if you just write "wine foobar".
Can you explain a bit better what's supposed to be the difference and why do you think it's a problem?
Hi !Quote:
Originally Posted by i92guboj
I was not thinking about the lowercase/uppercase difference.
The actual problem is :
When I run the Windows Program from a shortcut, the command line contains the executable filename and, as first parameter, the document filename.
Then, under LINUX, it has to open a filename like : /home/somefolder/somefile.txt
1) the normal slash is invalid for a Windows program.
2) A windows program cannot find /home. It can only find the drive letters provided through WINE.
How could we manage it to work ??
Well, now I see you point, but I still can't think why is it a problem.Quote:
Originally Posted by martinus
The links or whatever they are called that you define on a windows desktop are of the type "c:\program files\whatever\whatever.exe mydoc.doc", and the one in a kde desktop (for example) would be of the kind "wine ~/.wine/c_drive/program files/whatever/whatever.exe mydoc.doc".
Since they are completely unrelated stuff on completely unrelated oses, I fail to see why is that a problem, unless you are trying to program some kind of automatic tool to convert the windows .ink files to .desktop files to use them in linux.
I am puzzled, but maybe there's something trivial that I am not seeing.
Cheers.
EDITED: Ok, re-reading your question I think I understand it now. Run winecfg. There's a tab on that program to assign windows drive letters to your linux paths. I think that's what you are after.
Yes, it is trivial, I think !Quote:
Originally Posted by i92guboj
I rewrite the problem, which is :
When there is an association between a mime document type and a program, we run usually a command line containing, as parameter #1, the pathname of the document, using LINUX syntax ( /home/...), obviously not Windows one ( c:\my documents\...).
Since the Windows program expects in parameter #1 a pathname in Windows syntax, it can't work ! We assume that the Windows program can't be changed.
I was only trying to find an idea to workaround this, and allow running a Windows program, through wine, just by double-clicking a document on the linux desktop !
I can only imagine a small utility program reading the linux command line, changed to contain as parameter #1 the path of the windows program to run (instead of parameter #0) and as parameter #2 the linux path of the document(instead of parameter #1). Then, it could try to transform the linux pathname in a windows pathname, using the wincg data (if possible), and will end running another command line containing the windows program and the windows document pathname...
A bit complex, isn't it ? But maybe someone had already this idea and made it !
I use Gnome, but I don't think it makes any difference with Kde.
Regards.
Martin
Then read the part I edited on my last post. I think is what you are looking for.
But, can you explain how it can help ?Quote:
Originally Posted by i92guboj
It will not change the linux pathname sent to the windows program.
It will not change the way linux paths are written, but it will allow you to rewrite the paths on a windows-like fashion. For example, let's imagine that your home dir is /home/i92guboj/, let's imagine you have a file called mycd.iso there that you want to open with a windows program to edit isos or something.Quote:
Originally Posted by martinus
First, you type "winecfg" in a terminal, a window should appear with many tabs on it. There's a button to autodetect that usually works ok, but you can also add drives manually. You push the add button, and then you define a new drive letter (for example, h:) for /home/i92guboj/
Save the settings and close winecfg.
From now on, you can reffer to the file as h:\mycd.iso instead of /home/i92gubjo/mycd.iso. I think that's what you need, isn't it?
No, i92guboj, you have still not understood :confused:: I know how to create or edit a shortcut, but this is not where the problem is.
Again : the problem is with ASSOCIATIONS.
I need to have, in the second parameter of the command line, the pathname of the document file in Windows syntax, referring to WineCfg drives, instead of the linux pathname.
But I can't edit this pathname myself, it is made on the fly, when I double-click the document file. And the files can be anywhere on the system.
If you are talking about data which is generated on the fly then the thing is not that simple. You should be looking at which component is generating that data, and I don't think there's a way to do this without some patching in kdelibs and the involved program(s).Quote:
Originally Posted by martinus
EDIT: I said kdelibs for some reason, but for gnome it would be basically the same thing, requiring probably some heavy patching in gnome-vfs at least, and probably also no the rest of the involved programs.