Stephen Pair wrote:
> 
> Also, if you want to look native, then why not be native.  Just build
> frameworks to wrapper host OS windowing systems, then build
> abstractions that enable lowest common denominator type native widget
> portability (if desired).

Unfortunately, this doesn't work too well either (but it may work better
than a simulation approach).
The problem is that OS widgets don't usually work very well in an
outlandish place such as a Squeak window. They assume lots of things to
be installed, so Squeak would have to build a large machinery just to
create a pop-up button in Windows style. Well, buttons might be easy
enough actually, but the more complex widgets (like the collapsible
trees under Windows) expect and send a lot of very special messages.
Besides, these widgets are often extremely limited and don't fit well
with the mental concepts of Smalltalk. In Windows, a scrollbox
containing text strings is *very* different from a scrollbox having an
icon on each line (you'll have to program a callback for the latter).
You can appropriately package the whole thing and always prepare for the
most complex case, but it's *much* work. And doing things in the most
complex way so that Squeak has all possibilities available means you're
driving the underlying OS code to its edge, uncovering all the latent
bugs in it, and the version dependencies (some widgets work differently
under Windows NT 3.51 than under NT 4.0: other border sizes, for
example).
Try to do that over all the platforms that Squeak supports, and you get
a nightmare.

The greatest-common-divisor approach has been tried by several portable
GUI frameworks (Zinc etc.). It has generally been dropped because the
GCD is just too small and gets smaller with every additional UI (you'd
end up with a GCD that contains just buttons and single-line text
boxes).
So you end up wrappering some UI elements and simulating others.

I'm not sure which approach is actually better. Simulating everything
can be quite a pain in itself.


Thinking about it, I see an entirely different approach: Do both! And
let the developers decide which results they like best. And you can use
the native widget to regression-test the simulated widget.
The simulated widget would be needed anyway, even if native widgets were
the standard. Just imagine somebody selling a program, going around with
a laptop and showcasing it to all interested parties. With just native
widget, he'll have to have every conceivable OS on his laptop. With
simulated widgets, he'll be able to switch the system to the policy that
his audience likes best. (He'll even be able to insert a quote for
Squeak, e.g. to a Macintosh audience: "we're using the best available
technology - see, if anybody *insists* on a Windoze look-and-feel he can
have it with our software"... quite an Ahhh factor.)


Regards,
Joachim
-- 
Please don't send unsolicited ads.