Hi Torsten,

On Tue, Sep 16, 2014 at 4:12 PM, Torsten Bergmann <astares at gmx.de> wrote:

> Hi Eliot,
>
> Yes - in the past most Smalltalks did not have native widgets and usually
> emulated
> the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it
> was cool
> to run 1:1 on another machine it would have been to much manpower for the
> vendor
> to reimplement all the nice widgets to really look like the native system.
> Especially
> when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft.
>
> Even with good looking widgets/icons one could see from the speed and
> repainting issues
> (white rectangles for damage areas) that Smalltalk was not native. Also
> native widgets had
> other nice features like virtual modes for TreeViews/ListViews used if you
> want to display
> many nodes.
>
> Java faced the same problem - even with Swing and JavaFX today the Java
> UIs and especially
> the ugly JFileDialog never had this "Native look and easy navigation
> feeling". And yes
> there is SWT in Java providing native widgets - but how many applications
> are based on
> it? Only a few.
>
> On the ST side Smalltalk/MT and Dolphin use native widgets but were not
> portable. And if
> you look at others like VW, VAST or Smalltalk/X you will see that
> engineers are good at
> creating powerfull systems but often fail when it comes to UI design and
> usability. Squeak
> was special and flexible with Morphic (even without multiple windows) -
> but looked too toyish.
>
> So yes - customers of commercial Smalltalk vendors asked for "Native"
> because if you had
> built a UI in Smalltalk it was part of a rich client application and often
> people compared
> it to other native applications or new widgets found in MS Office.
>

That's a great summary. +1.


> But in the past customer also asked for COM/COM+, CORBA and webservices
> while today
> it is often much easier to exchange data or call functionality via HTTP,
> REST, ...
>

Sure, but that's invisible glue; not the same as UI components for the
user.  So there's a bit of a non-sequitur extrapolating from UI (user to
system) to system to system connectivity.


> So time and expectations have changed a lot meanwhile. Especially for the
> UI's.
> Desktop platforms unite with the web and in the web it is also possible to
> look more
> like platforms or style to look like a native app. See [1] and [2] for two
> simple examples.
>
> While the browsers and JS engines become faster this will also change more
> the way
> we think about applications: no installation, styleable, clear look. The
> google
> chrome experiments are a good page to see how this will soon look like.
> And we will
> be independent from devices and screen resolution. In fact more and more
> applications
> we use today run on a computers webbrowser, tablet or a smartphone (often
> the same way).
>
> With Morphic (even when it has Fenestri) we can not compete agains
> HTML/CSS on the
> UI side. The Canvas element and WebGL will also drive this forward.
> Even if one does not like web technologies - it currently is the platform
> where
> you reach people easily.
>
> Smalltalk should/could have a place in this (web centric) world:
>
>   1. As a backend to serve the web
>   2. On the client
>   3. Combining 1. and 2.
>
> For the first we have Seaside, TeaPot, Aida, ...
> For the seond: as it will not happen that browser vendors agree and threw
> out JavaScript in
> favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do.
>
> But we should also rethink Smalltalk to find a better place as a scripting
> language. What
> I still would like to see:
>
>  - tiny and fast VM with a command line and REPL
>

We're getting there with fast.  Tiny needs more definition, but the core
Cog/Spur VM on Mac minus plugins and GUI code is 568k, 506k code, 63k data;
the newspeak VM which has fewer primitives but support for two bytecode
sets is 453k, 386k code, 68k data.  That includes the interpreter, JIT,
core primitives and memory manager/GC. Add on several k for the FFI, C
library et al and a VM in a megabyte is realistic.  Is that in the right
ball park?

 - one unified and easy to use FFI with callbacks so one can use the
> platform, maybe
>    others will write the bindings then
>

+1.  Again that's central to our efforts.


>  - single small base image but fast loadable binary code components
> (modules, maybe using the
>    LoadLibrary trick), similar to what David had with SmallScript or what
> BeeSmalltalk is doing with SLL's
>

Yep.  But personally I think Fuel is better and just as fast.  Certainly
that's the parcels experience.


>  - but still with the ability to bootstrap up to a full saveable image
>

+1.


>  - ability to serve the web with easy callbacks into Smalltalk for
> implementing functionality
>    (especially with this we may catch 90% of the usual UI cases).
>

This we'll leave to the web framework designers, but it seems eminently
doable no?


>
> Bye
> T.
>
> [1] Metro theme Bootstrap
> http://talkslab.github.io/metro-bootstrap/components.html
> [2] jQuery Desktop http://desktop.sonspring.com/
> [3] Chrome Experiments http://www.chromeexperiments.com/


I love the circle game but oh boy does the implementation show through in
the pauses.  My old 5.x Safari pauses noticeably every two seconds or so.
Chrome is smooth.

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140917/c968ed77/attachment.htm