This thing of "lowest common denominator" (LCD) is something
I've been thinking about lately. I've been using wxPython
exclusively for the past 2 years and I like it, but one of my
colleagues thinks it is the wrong approach. His reasoning is
that by using native toolkit the GUI ends up with the LCD, and
the more platforms you support, the lower the LCD becomes.
If it were true that using the native toolkit meant that you got LCD
functionality, then yes, your colleague may have a point (but see below).
But it's simply *not* true, and wxWindows (wxPython) is the counterexample.
wxWindows (wxPython) does *not* give LCD functionality with native toolkits.
The environment is very rich, and most definitely *not* lacking in
functionality. I only work on one platform, so I can't comment on how this
is achieved, or what caveats there are when writing for multiple platforms,
but I do know that wxWindows (wxPython) is a very rich environment for
Windows development. And I believe that most (if not all) of the features
work cross-platform.
(For example, when the Mac version of wxPython gets launched it
will probably start with a very low LCD.)
Er, can you explain that? The Mac version cannot have a LCD - the "C" means
"Common" - you can't be "common" across a single platform! If you mean that
the Mac version will have limited functionality, then yes - so what? The
design goal is (as I understand it) to have (as near as possible) all
features available on all platforms. If the Mac hasn't got to that stage
yet, fine - that just makes the Mac "not completely supported yet". If the
*design goal* was to have a limited set of functions which were the only
ones supported across platforms, then fair enough, wxWindows (wxPython)
would be a very limited toolkit for cross-platform development (with very
extensive platform-specific extensions) but that's not how I see it...
He thinks that non-native toolkit is the way to go because the
toolkit is written once and it works the same on all platforms.
You can achieve a certain look with themes.
The most major problem with non-native toolkits is that they *don't* achieve
a native look. The user can see the results of the developer's
implementation decisions, which is (IMNSHO) a very bad thing. TCL/Tk
applications used to have this problem (although I believe they now use
native underlying calls, and are a lot better). Java applications are
utterly dreadful in this regard - all sorts of annoying UI issues (tab key
not moving between controls correctly, cut&paste not always working from
certain controls, no way of using some controls without a mouse, etc).
Frankly, the amount of effort involved in doing a 100% job on a non-native
toolkit is not practical. So all non-native toolkits I've seen make the
user's job less easy (by not conforming to standard platform behaviour) for
the sake of saving the developer's time (by reducing cross-platform issues).
This is, to my mind, self-evidently wrong... For a simple example, how much
effort would it take to 100% emulate all of the features of MS Windows
scrollbars - including mouse wheel support, line and page scrolling, look
and feel customisation via the control panel, keyboard control, etc, etc?
What is the benefit over reusing the existing MS control? Who is qualified
to decide that no user cares about any particular aspect of the MS
fnctionality, and omit it?
Personally, if I can (as a user) tell that an application does not use
native widgets, I will tend to avoid that application. Some of my colleagues
aren't that extreme, but I usually find that I hear a continual stream of
"what a pain - I can't do X" type comments over such applications (which
gives me a lovely feeling of self-justification :-))
But at the end of the day, this is one of those religious issues with no
real resolution.
Paul.
ยทยทยท
From: Bob Klimek [mailto:klimek@grc.nasa.gov]