[Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

gettimothy gettimothy at zoho.com
Wed Sep 17 11:59:52 UTC 2014


What Torsten said.

When I get the darn CMake stuff done, I will be turning to REPL work and multi-core work (assuming I develop the chops to get it done)

Put a factory pattern in place where morphic currently launches and provide a 'seaside' gui rendering engine using the renderContentOn: aCanvas idiom as an option.
Use both for the web and the desktop and let CSS folks design their looks and feels.

my $0.02.

cordially,

tty





---- On Tue, 16 Sep 2014 16:12:05 -0700 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. 
 
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, ... 
 
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 
 - one unified and easy to use FFI with callbacks so one can use the platform, maybe 
 others will write the bindings then 
 - 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 
 - but still with the ability to bootstrap up to a full saveable image 
 - 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). 
 
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/ 
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140917/9570d321/attachment-0001.htm


More information about the Squeak-dev mailing list