<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'>What Torsten said.<br><br>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)<br><br>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.<br>Use both for the web and the desktop and let CSS folks design their looks and feels.<br><br>my $0.02.<br><br>cordially,<br><br>tty<br><br><br><br><br><div id="1"><br>---- On Tue, 16 Sep 2014 16:12:05 -0700 <b>Torsten Bergmann <astares@gmx.de></b> wrote ---- <br></div><br><blockquote style="border-left: 1px solid #0000FF;padding-left: 6px; margin: 0 0 0 5px">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> <br>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> <br>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> - one unified and easy to use FFI with callbacks so one can use the platform, maybe <br> others will write the bindings then <br> - 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> - but still with the ability to bootstrap up to a full saveable image <br> - 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> <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> <br> <br></blockquote><br></div></body></html>