Charles Miller wrote:
>
> JTK wrote:
>
> > And am I mistaken, or has nobody yet come up with a passable explanation
> > as to why the file save dialogs have been singled out as 'native is OK',
> > while virtually nothing else is, eg tree controls?
>
> The cross-platform widget set is used when an identical interface is
> required across operating systems.
Just to clarify, you mean 'look and feel' when you're saying 'interface'
here (so we don't get it confused with 'API').
> File selection dialogs can _not_ be
> identical across operating systems, because each OS has different file
> semantics. For example, the Unix filesystem is single-rooted, whereas
> Win32 has a root for each physical or mapped drive, and needs interfaces
> to access virtual locations such as the "Network Neighbourhood" and "My
> Computer".
>
> Each OS would need its own, custom save dialog anyway, so it would be
> unfeasable to write a cross-platform replacement.
>
It most certainly *would* be feasible (though a mistake) to implement
such a replacement. Hell, what do you think Swing does? Well, not that
Swing's disastrous story bolsters my overall argument, but let's assume
Swing was actually done right, in a compiled language.
> In addition, the interface for a file save dialog is really, really
> simple.
No, it isn't. Not on Windows anyway. Here's the structure you have to
fill out and pass to GetOpenFilename() or GetSaveFielname():
typedef struct tagOFN {
DWORD lStructSize;
HWND hwndOwner;
HINSTANCE hInstance;
LPCTSTR lpstrFilter;
LPTSTR lpstrCustomFilter;
DWORD nMaxCustFilter;
DWORD nFilterIndex;
LPTSTR lpstrFile;
DWORD nMaxFile;
LPTSTR lpstrFileTitle;
DWORD nMaxFileTitle;
LPCTSTR lpstrInitialDir;
LPCTSTR lpstrTitle;
DWORD Flags;
WORD nFileOffset;
WORD nFileExtension;
LPCTSTR lpstrDefExt;
LPARAM lCustData;
LPOFNHOOKPROC lpfnHook;
LPCTSTR lpTemplateName;
#if (_WIN32_WINNT >= 0x0500)
void * pvReserved;
DWORD dwReserved;
DWORD FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
} OPENFILENAME, *LPOPENFILENAME;
Members
I somehow doubt it's anywhere near similar to its analog on eg Linux.
But don't take this the wrong way, I completely agree with your basic
premise on this: there's absolutely no reason why the native file open
dialogs on the various platforms that Mozilla has chosen to support (no
matter how irrelevant they may be) cannot be wrapped quite
straightforwardly and their differences abstracted away.
Where we of course differ is that I know that this same premise extends
to all other common dialogs and controls.
> You tell it where to start and what sort of files you're looking
> for, and then it gives you back a filename. Since the interface is
> simple, the effort required to plug a new dialog in is small.
>
> The interface to a tree control is far more complex. It's not just
> "here's a list of things in the tree, display them".
Yeah, it pretty much is. That gets you quite a ways anyway.
> It's "how do I
> notify the tree when this branch, and only this branch has changed?"
Yep, you've got to have that sort of stuff too.
> "How do I make it so that when someone right-clicks (or option-clicks)
> on a node of type foo, they get this particular context-sensitive menu?"
> "What's the interface for dragging and dropping something onto a node of
> the tree?" The way these things are handled vary wildly between
> platforms,
...yet they are conceptually the same,...
> and make porting a total nightmare.
>
And yet wxWindows seems to be able to handle it just fine, even though
they don't have the advantage of AOL's checkbook. And I just downloaded
a simple wxWindows app that even had some basic *skinning* going on!
> Charles Miller
