On Tue, Jan 04, 2005 at 11:22:00AM -0500, Dan Notestein wrote:
This patch allows winelib to be conditionally compiled with USE_NATIVE_UNIX_PATHS macro. Enabling this will cause the common dialogs to display using unix paths instead of drive letters.
This would be much better as a registry setting, not a compile time option.
On Tue, 04 Jan 2005 11:30:32 -0500, Dimitrie O. Paun wrote:
This would be much better as a registry setting, not a compile time option.
It needs to be an API switch really as it's a per-app thing, only programs written to expect it should get UNIX names. But this is similar to the discussion we had before and what form the API should take (no firm decision made).
On Tue, Jan 04, 2005 at 04:57:15PM +0000, Mike Hearn wrote:
It needs to be an API switch really as it's a per-app thing, only programs written to expect it should get UNIX names. But this is similar to the discussion we had before and what form the API should take (no firm decision made).
Actually, there are two independent issues here: 1. How paths are presented to the user This is user preference, and should be a registry setting 2. How paths are presented to the app This is something that needs to be per app. One way to do it would be to follow Miscrosoft and ornate apps somehow (the same they do for themable apps) via some sort of manifest that would request Unix paths instead of DOS ones. Same mechanism could be used for other things, like requesting native open dialogs instead of ours, etc.
On Tue, 2005-01-04 at 12:11 -0500, Dimitrie O. Paun wrote:
Actually, there are two independent issues here:
- How paths are presented to the user This is user preference, and should be a registry setting
Yeah. It'd be nice to improve this, but we're limited by the dumb design of the open dialog API. We can't change its UI design very much and we can't use native file dialogs because apps can customise them. Unless we're OK with apps having a mix of native and win32 dialogs of course.
There's also the confusion from selecting /home/mike/Foo.doc in the open dialog but having the title bar say X:\foo.doc or whatever.
- How paths are presented to the app This is something that needs to be per app. One way to do it would be to follow Miscrosoft and ornate apps somehow (the same they do for themable apps) via some sort of manifest that would request Unix paths instead of DOS ones. Same mechanism could be used for other things, like requesting native open dialogs instead of ours, etc.
Mmmm, the manifest thing seems horribly complicated to me. Seems like a use of XML just for the sake of it. When extending win32 we don't have to follow their dubious design decisions (one reason why I'm not keen on magic PIDLs and such).
thanks -mike
On Tue, Jan 04, 2005 at 05:29:10PM +0000, Mike Hearn wrote:
On Tue, 2005-01-04 at 12:11 -0500, Dimitrie O. Paun wrote:
Actually, there are two independent issues here:
- How paths are presented to the user This is user preference, and should be a registry setting
Yeah. It'd be nice to improve this, but we're limited by the dumb design of the open dialog API. We can't change its UI design very much and we can't use native file dialogs because apps can customise them. Unless we're OK with apps having a mix of native and win32 dialogs of course.
There's also the confusion from selecting /home/mike/Foo.doc in the open dialog but having the title bar say X:\foo.doc or whatever.
This is why it's a user preference. But this, mind you, has nothing to do with a native dialog. This preference would control the behaviour of *our* dialog. Our vs. native dialog is a completely different setting, and it's a app-specific one, as noted below.
- How paths are presented to the app This is something that needs to be per app. One way to do it would be to follow Miscrosoft and ornate apps somehow (the same they do for themable apps) via some sort of manifest that would request Unix paths instead of DOS ones. Same mechanism could be used for other things, like requesting native open dialogs instead of ours, etc.
Mmmm, the manifest thing seems horribly complicated to me. Seems like a use of XML just for the sake of it. When extending win32 we don't have to follow their dubious design decisions (one reason why I'm not keen on magic PIDLs and such).
I have no idea how their manifest looks like, be it XML or not, but I find the idea OK. Being an app specific setting, it should be bound to the application somehow. And being able to "stamp" the app with ceratin settings sounds better then inveting all sorts of apps, for things that are truly app global.
On Tue, 4 Jan 2005, Dimitrie O. Paun wrote: [...]
- How paths are presented to the app This is something that needs to be per app. One way to do it would be to follow Miscrosoft and ornate apps somehow (the same they do for themable apps) via some sort of manifest that would request Unix paths instead of DOS ones. Same mechanism could be used for other things, like requesting native open dialogs instead of ours, etc.
Shouldn't this be a per-call thing rather than a per-app thing?
An application may be built from multiple components, some of which may not support being given a Unix path. Here are two scenarios where this might be an issue: * COM embedding A Unix path aware app embeds a COM component which presents a dialog to the user for some reason. IF the flag is app-global the COM component will get a Unix path and be confused.
* An application supporting plugins It's a similar issue: that the app supports Unix paths does not mean that all its plugins support them. For instance a Winelib web browser that would load an HTML page that uses an ActiveX component to display a PDF file. That ActiveX component may have a button that lets the user save the PDF file. This button would open a dialog and if that dialog uses the application's global flag it would return a Unix path.
The short of it is that only the code invoking the common dialog knows whether it is prepared to deal with Unix paths or not and thus is the only one who can say whether the dialog should return Unix paths.
-
Dimitrie O. Paun -
Francois Gouget -
Mike Hearn