<div dir="ltr">Hi Torsten,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 16, 2014 at 4:12 PM, Torsten Bergmann <span dir="ltr"><<a href="mailto:astares@gmx.de" target="_blank">astares@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eliot,<br>
<br>
Yes - in the past most Smalltalks did not have native widgets and usually emulated<br>
the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it was cool<br>
to run 1:1 on another machine it would have been to much manpower for the vendor<br>
to reimplement all the nice widgets to really look like the native system. Especially<br>
when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft.<br>
<br>
Even with good looking widgets/icons one could see from the speed and repainting issues<br>
(white rectangles for damage areas) that Smalltalk was not native. Also native widgets had<br>
other nice features like virtual modes for TreeViews/ListViews used if you want to display<br>
many nodes.<br>
<br>
Java faced the same problem - even with Swing and JavaFX today the Java UIs and especially<br>
the ugly JFileDialog never had this "Native look and easy navigation feeling". And yes<br>
there is SWT in Java providing native widgets - but how many applications are based on<br>
it? Only a few.<br>
<br>
On the ST side Smalltalk/MT and Dolphin use native widgets but were not portable. And if<br>
you look at others like VW, VAST or Smalltalk/X you will see that engineers are good at<br>
creating powerfull systems but often fail when it comes to UI design and usability. Squeak<br>
was special and flexible with Morphic (even without multiple windows) - but looked too toyish.<br>
<br>
So yes - customers of commercial Smalltalk vendors asked for "Native" because if you had<br>
built a UI in Smalltalk it was part of a rich client application and often people compared<br>
it to other native applications or new widgets found in MS Office.<br></blockquote><div><br></div><div>That's a great summary. +1.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But in the past customer also asked for COM/COM+, CORBA and webservices while today<br>
it is often much easier to exchange data or call functionality via HTTP, REST, ...<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So time and expectations have changed a lot meanwhile. Especially for the UI's.<br>
Desktop platforms unite with the web and in the web it is also possible to look more<br>
like platforms or style to look like a native app. See [1] and [2] for two simple examples.<br>
<br>
While the browsers and JS engines become faster this will also change more the way<br>
we think about applications: no installation, styleable, clear look. The google<br>
chrome experiments are a good page to see how this will soon look like. And we will<br>
be independent from devices and screen resolution. In fact more and more applications<br>
we use today run on a computers webbrowser, tablet or a smartphone (often the same way).<br>
<br>
With Morphic (even when it has Fenestri) we can not compete agains HTML/CSS on the<br>
UI side. The Canvas element and WebGL will also drive this forward.<br>
Even if one does not like web technologies - it currently is the platform where<br>
you reach people easily.<br>
<br>
Smalltalk should/could have a place in this (web centric) world:<br>
<br>
1. As a backend to serve the web<br>
2. On the client<br>
3. Combining 1. and 2.<br>
<br>
For the first we have Seaside, TeaPot, Aida, ...<br>
For the seond: as it will not happen that browser vendors agree and threw out JavaScript in<br>
favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do.<br>
<br>
But we should also rethink Smalltalk to find a better place as a scripting language. What<br>
I still would like to see:<br>
<br>
- tiny and fast VM with a command line and REPL<br></blockquote><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- one unified and easy to use FFI with callbacks so one can use the platform, maybe<br>
others will write the bindings then<br></blockquote><div><br></div><div>+1. Again that's central to our efforts.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- single small base image but fast loadable binary code components (modules, maybe using the<br>
LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's<br></blockquote><div><br></div><div>Yep. But personally I think Fuel is better and just as fast. Certainly that's the parcels experience.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- but still with the ability to bootstrap up to a full saveable image<br></blockquote><div><br></div><div>+1.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- ability to serve the web with easy callbacks into Smalltalk for implementing functionality<br>
(especially with this we may catch 90% of the usual UI cases).<br></blockquote><div><br></div><div>This we'll leave to the web framework designers, but it seems eminently doable no?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Bye<br>
T.<br>
<br>
[1] Metro theme Bootstrap <a href="http://talkslab.github.io/metro-bootstrap/components.html" target="_blank">http://talkslab.github.io/metro-bootstrap/components.html</a><br>
[2] jQuery Desktop <a href="http://desktop.sonspring.com/" target="_blank">http://desktop.sonspring.com/</a><br>
[3] Chrome Experiments <a href="http://www.chromeexperiments.com/" target="_blank">http://www.chromeexperiments.com/</a></blockquote><div><br></div><div>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.</div></div><br>-- <br>best,<div>Eliot</div>
</div></div>