JTK wrote:
> Just to clarify, you mean 'look and feel' when you're saying 'interface'
> here (so we don't get it confused with 'API').
The word is overloaded, but in this case I mean both. For Mozilla to
efficiently support cross-platform code, the API needs to be uniform so
that writers of XP (now there's another overloaded term) code don't have
to cater for each different windowing toolkit, and also the look and
feel needs to be uniform in the sense that if you lay out a UI on one
platform, it will be just as useable on other platforms.
Uniformity of look and feel to the user is not really important - it
doesn't matter if the application looks different on Windows and Linux,
because in an ideal world, the windowing system is supposed to dictate
the UI. In that world, there would be significantly different front-ends
written for Windows, MacOS, BeOS, generic X, GNOME, KDE and OS/2, each
designed from the ground up against the User Interface Bible of the
particular environment. (Or in the case of X, just thrown together
randomly).
> > 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?
In an earlier draft of the paragraph I used Swing's JFileChooser as an
example of the sort of monstrosity you end up with when you try to write
a cross-platform filechooser.
On the other hand, I also cut the "Swing vs AWT" comparison because it
was particularly unfair on native widget sets, as AWT never matured past
being a truly disgusting hack thrown together at the last minute.
> Where we of course differ is that I know that this same premise extends
> to all other common dialogs and controls.
As I said, the difference between a file chooser and anything else, is
that a file chooser is an interface to something that is quite
particular to the operating system, and thus writing a cross-platform
replacement that doesn't suck (unlike JFileChooser) really means writing
a new filechooser for each OS anyway.
Also, being a dialog, the file chooser is distinct from a control like a
tree, textbox or list because it never needs to be embedded inside
anything else, doesn't form part of layout, doesn't need to be
manipulated during flight by other parts of the application - it just
needs to be launched, ignored, and then have its result checked.
This could be an argument for more alert boxes and dialogs native, but
having to start asking "So is this one a native or an XUL window?" would
probably be a loss in terms of complexity - the file chooser is a pretty
clear-cut case, but "transient windows that don't need more than a
particular complexity" wouldn't be.
Thus, writing an abstraction layer on top of native file chooser dialogs
is far more of a win than it would be for other controls. The only gain
you'd get if you made the file chooser XUL is that it'd become
skinnable, and nobody actually cares about skinnability except you. ;)
> > 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.
What was that quote about the last 10% of functionality accounting for
50% of the time?
> 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!
wxWindows also has about six years head-start in development time. That
said, the variant of the LGPL that wxWindows uses seems to be compatible
with the NPL - it allows for proprietary binary-only distributions. I've
not encountered wxWindows before today, though, so I can't comment on
its suitability for Mozilla.
On a side-note, wxWindows had to write its own tree control:
http://www.wxwindows.org/faqgen.htm
"Another reason why wxWindows 2 is not a 'lowest common denominator'
toolkit is that some functionality missing on some platform has been
provided using generic, platform-independent code, such as the
wxTreeCtrl and wxListCtrl classes."
Charles Miller
