Hi Michael, > Oops, as you see I'm undecided ;) (Anyway, this probably should be GNU ;)
However, in the final version I would like this to appear not at all in the shell namespace, anyway. I think it would be nice if the '/' appears beside the wine drive letters under 'My Computer'.
I have been extending your work to integrate shfldr_unixfs more with open file dialog. I am modifying open file dialog to accept typed in unix path and through validation checks as well I have also fixed a bug in shfldr_unixfs and extend IPersistFolder to IPersistFolder2.
I know you are working on this area as well, so maybe we should coordinate our effort so that there is no duplicate work.
I know there will be issues of Windows APIs won't accept unix file path. But at this point, I just want to extend open file dialog optionally accept and return a unix file path.
The flag to turn unix path on or off can be in the registry, or simply a extended flag that was passed in to OPENFILENAME struct.
Michael Lin
On 5/4/05, Michael Lin mlin@corvu.com.au wrote:
I know there will be issues of Windows APIs won't accept unix file path. But at this point, I just want to extend open file dialog optionally accept and return a unix file path.
The flag to turn unix path on or off can be in the registry, or simply a extended flag that was passed in to OPENFILENAME struct.
I don't agree with your decision to pass in unix file paths to the open file dialog et al. The gateway to wine's interaction with the unix filesystem is through wine's virtual drives. In particular Z: is usually set up to point to the root directory of the unix filesystem, and if you want to find a file within the unix filesystem you browse through the virtual Z drive. You can't type in a unix file path in windows, so I don't see why we should allow it in wine. That is what the virtual drives are for.
Objections aside, if you really want to implement this and everyone else agrees with you, there are internal functions that turn a unix file path into a windows file path. I suggest using either this or something similar instead of trying to send a unix path to OpenFile etc and passing around flags in the registry and modified structures.
On Thu, 05 May 2005 08:06:40 +0200, James Hawkins truiken@gmail.com wrote:
You can't type in a unix file path in windows, so I don't see why we should allow it in wine. That is what the virtual drives are for.
I agree. I would have thought the over-riding principal is to keep functionalily as close as possible to windows behaviour to provide the closest compatability possible, not to start adding "extentions".
If we need to regularly access another part of the unix file system it can be set up as a virtual drive or sim-linked into the .wine file structure.
I dont see a real need for this feature.
Regards.
On 5/5/05, wino@piments.com wino@piments.com wrote:
I agree. I would have thought the over-riding principal is to keep functionalily as close as possible to windows behaviour to provide the closest compatability possible, not to start adding "extentions".
If we need to regularly access another part of the unix file system it can be set up as a virtual drive or sim-linked into the .wine file structure.
I dont see a real need for this feature.
We do need this for winecfg. If you want to setup virtual drive you do want to see the full unix fs. Winecfg needs to have to unix paths. Putting conversion code in winecfg was not really acceptable, an extension to was.
This extension will become even more valuable because we want winecfg (or wine in particular) to start without having any virtual drive. People might have removed all drives (with winecfg).
Paul
On Thu, 05 May 2005 08:51:44 +0200, Paul van Schayck polleke@gmail.com wrote:
This extension will become even more valuable because we want winecfg (or wine in particular) to start without having any virtual drive. People might have removed all drives (with winecfg).
Isnt that like trying to start windows without c: ?
On Thu, 5 May 2005, James Hawkins wrote: [...]
You can't type in a unix file path in windows, so I don't see why we should allow it in wine. That is what the virtual drives are for.
I believe the rationale is to provide a better integration with the Unix environment. Here's the scenario where I see this used.
Some ISV, e.g. Borland, ports their popular application, e.g. Kylix, to Linux using Wine and/or Winelib. With Wine as it stands, their 'Unix' application still display Windows paths in the File Open dialogs, thus causing an outcry from Unix users that they don't want to have to deal with Windows drives, that it's not a real port, that ports done with Wine suck, etc.
This is where this extension intervenes: it lets the application ask for a Unix File Open dialog, thus giving a more native look to the application. Note that it's quite possible the application will turn around and immediately convert the path back to a Windows path using the APIs you mentioned and a, now hidden, Z: drive. But, if done well, that's none of the user's concern, all that counts here is what the user sees in the File Open dialog.
Hi,
The stuff, which is implemented in shell32/shfldr_unixfs.c is what Microsoft calls a "shell namespace extension". This is used quite often on Windows, for example to access some non USB-mass-storage based digital cameras via the shell. We use this extension in winecfg to map drive letters to unix paths. For this use case we are within the standard Win32 API: No extensions to the API whatsoever.
As far as I understand it up to now, it would also be possible to select unix paths without API modifications in the file open dialog if the OFN_NOVALIDATE flag is set. This true only if you register a "Junction Point" for the "shell namespace extension" to map it to some point in the shell namespace. The problem is, if we do this by default, we will always have the unix filesystem in our dialogs. This is probably not what we want. Winelib applications, which have their one .wine environment, could use it this way, however.
The question is if we want some extra API, which allows an application to request for the unix file system to be displayed, even if no junction point is registered. I don't know if we should do this and where we would put it.
Bye,
On Thu, 5 May 2005 19:42, Francois Gouget wrote:
I believe the rationale is to provide a better integration with the Unix environment....> Some ISV, e.g. Borland, ports their popular application, e.g. Kylix, to Linux using Wine and/or Winelib. With Wine as it stands, their 'Unix' application still display Windows paths in the File Open dialogs, thus causing an outcry from Unix users that they don't want to have to deal with Windows drives, that it's not a real port, that ports done with Wine suck, etc.
Precisely. WINE is not just for running apps compiled for Windows - it's also for making the Windows API available under UNIX. For this second application, users need to (at a minimum) be seeing UNIX paths (and not Windows paths at all) in the dialog. It is also reasonable in this context for the application to expect to use APIs with UNIX paths without having to convert them.
I'm leaning toward the separate entry point solution (the various approaches were canvassed here a couple of weeks ago) since it avoids problems with Microsoft adding new flags of their own later that use the same values as WINE specific flags.
On 5/5/05, Troy Rollo wine@troy.rollo.name wrote:
Precisely. WINE is not just for running apps compiled for Windows - it's also for making the Windows API available under UNIX. For this second application, users need to (at a minimum) be seeing UNIX paths (and not Windows paths at all) in the dialog. It is also reasonable in this context for the application to expect to use APIs with UNIX paths without having to convert them.
wine wasn't designed to accept unix paths in the apis directly or to display them in open file dialogs, and that's why we have virtual drives.
I'm leaning toward the separate entry point solution (the various approaches were canvassed here a couple of weeks ago) since it avoids problems with Microsoft adding new flags of their own later that use the same values as WINE specific flags.
This just adds complexity to an already complex beast. Keep it simple.
On Fri, 6 May 2005 09:10, James Hawkins wrote:
wine wasn't designed to accept unix paths in the apis directly or to display them in open file dialogs,
Linux wasn't designed to run Windows applications either - these things are subject to change.
and that's why we have virtual drives.
No, virtual drives are there because they're needed for native applications.
This just adds complexity to an already complex beast. Keep it simple.
If it's too complex for *you* then nobody's asking *you* to implement it. It's needed for some uses of WINE, and we have at least one corporate developer and one individual developer who are willing to implement it. This pretty much guarantees something will be implemented whether it's beyond your capabilities or not. The only real question is what is the best *way* to implement it.
On 5/5/05, Troy Rollo wine@troy.rollo.name wrote:
Linux wasn't designed to run Windows applications either - these things are subject to change.
By this argument we should have changed linux itself to run windows programs. If things are subject to change, like creating wine on top of linux to run windows programs, then the next logical step is to create a new project on top of wine to allow unix paths in file open dialogs. This is just following your logic of course; I would never suggest actually doing that.
No, virtual drives are there because they're needed for native applications.
I'm not sure what you mean by native applications. Native linux/wine/win32 apps? Virtual drives are a part of the design on wine. Even if we only used winelib with ported applications, you still run them with wine, and the very first time you run wine, a .wine directory will be created along with the drive_c. It's not just for native applications.
This just adds complexity to an already complex beast. Keep it simple.
If it's too complex for *you* then nobody's asking *you* to implement it. It's needed for some uses of WINE, and we have at least one corporate developer and one individual developer who are willing to implement it. This pretty much guarantees something will be implemented whether it's beyond your capabilities or not. The only real question is what is the best *way* to implement it.
Let's not go putting words in my mouth. I never said it would be complex for me or anyone else to implement. If you'll remember what I said earlier:
"Objections aside, if you really want to implement this and everyone else agrees with you, there are internal functions that turn a unix file path into a windows file path. I suggest using either this or something similar instead of trying to send a unix path to OpenFile etc and passing around flags in the registry and modified structures."
I never said you or someone else shouldn't implement it, and even gave suggestions for if you do implement it. Please be my guest. I only object to the reason for implementing it, and that's perfectly normal around here. Not everyone will agree with the things you want done in wine.
Back to the complexity topic. The implementation is not complex...the design is. Complexity is a design flaw. When you make things more complex than it really needs to be, it becomes unwieldly, buggy, and difficult to maintain. What we have now works well. For those familiar with windows, having virtual drives is perfect, and for those familiar with linux, it's not a big problem to run over to Z:\ and head to your file.
If you have anything else to say about this topic, limit it to why you think it's essential or beneficial to use unix paths, or to how you yourself would design such a thing, and not about mine or anyone else's programming ability.
Troy Rollo wrote:
If it's too complex for *you* then nobody's asking *you* to implement it. It's needed for some uses of WINE, and we have at least one corporate developer and one individual developer who are willing to implement it. This pretty much guarantees something will be implemented whether it's beyond your capabilities or not. The only real question is what is the best *way* to implement it.
What I did is a solution totally out of wine. I changed the File-Dialog code to load KDE native, and use the Unix-2-windows Wine API(s) before calling the Win32 API. Same for a few Edit boxes that hold file paths. Inside was all Win32 only the highest GUI level was abstracted in a Class that hides it all. (Different file implementation in Makefiles). This and the Z: drive in setup and I was covered. It is an outside wine solution. One could submit it as a Winelib only code. I cannot send my code as it is not Licensed to me, and any way it is in C++ and using a very strange GUI lib.
Free Life Boaz
James Hawkins wrote:
On 5/5/05, Troy Rollo wine@troy.rollo.name wrote:
Precisely. WINE is not just for running apps compiled for Windows - it's also for making the Windows API available under UNIX. For this second application, users need to (at a minimum) be seeing UNIX paths (and not Windows paths at all) in the dialog. It is also reasonable in this context for the application to expect to use APIs with UNIX paths without having to convert them.
wine wasn't designed to accept unix paths in the apis directly or to display them in open file dialogs, and that's why we have virtual drives.
Whether or not wine was originally designed for this, winelib as it exists right now is great for making a unix-native version of a windows program. The commercial porting library I have experience with behaves exactly this way -- Windows API functions took and returned native unix paths, and everything displayed to the user looked like a normal unix path. We found this to be a very natural way for a porting library to behave.
I'm not saying that this should be the only way winelib should behave, or even that it should be the default way. It seems like several of us have already made our own hacks to get winelib to work this way -- it would be a shame not to at least make unix paths an option.
In our application, we would often take a filename that came from a windows API function, (say, a Save File dialog), and do something like construct a std::ofstream() using that path. Since the standard library wasn't compiled against wine, it gets confused by the windows paths, and creates a file named 'z:\tmp\foo.txt' in the current directory, instead of '/tmp/foo.txt' like I want it to. Yes, we could've figured out how to compile all of our third-party libraries against wine and it would've worked, but that can be a *lot* of work and you still don't end up with an application that looks at home on unix.
I'm leaning toward the separate entry point solution (the various approaches were canvassed here a couple of weeks ago) since it avoids problems with Microsoft adding new flags of their own later that use the same values as WINE specific flags.
This just adds complexity to an already complex beast. Keep it simple.
So far, the separate entry point solution sounds like the best one to me also, at least for selecting what the API functions expect & return. I'm not sure about the best way to select whether unix paths are displayed to the user or not. Since that could also benefit windows-native applications, that preference might be better off stored in the registry or elsewhere.
Eric
Hi Michael,
On Thursday 05 May 2005 03:06, Michael Lin wrote:
I know you are working on this area as well, so maybe we should coordinate our effort so that there is no duplicate work.
I do have a couple of patches, which are not yet ready to be send to wine-patches. I will finish them up and submit them (Hopefully until the end of the week). I'm not planing to go a lot further on the unixfs stuff after this, but would rather like to focus on the crypto stuff, which I've worked on before. What I meant to say is, once I've submitted my last couple of patches, feel free to take over. It seems like you are having a real world use case for this stuff?
Bye,
-
Boaz Harrosh -
Eric Frias -
Francois Gouget -
James Hawkins -
Michael Jung -
Michael Lin -
Paul van Schayck -
peter＠piments.com -
Troy Rollo -
wino＠piments.com