Hi Torsten, On Tue, Sep 16, 2014 at 4:12 PM, Torsten Bergmann <asta...@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