The Dilemma: Building a Futuristic GUI for Ephestos

The problem with relying for everything on smalltalk code and not using existing technology is two fold

a) You cannot compete with existing solution, they come with more manpower , have more features, better documention, more bug fixes, more, more ...... more

b) One day the authors of the library decide to give up on the library because they went off to other things and of course it falls to the shoulders of others that are much less motivated and have other things in their plate too with higher priority for them. The library continues to improve but at a glacial pace. 

Its perfectly ok to try your own things and follow your own road. Everyone loves to experiment and do things his own way and that has many positive. But the general refusal to embrace existing technologies even problematic ones make the job of spreading the Smalltalk appeal much harder. Makes it harder for people to transition from other languages too.

This smalltalk mentality is wrong. The end. 

On Tue, Sep 16, 2014 at 12:11 AM, Eliot Miranda <[hidden email]> wrote:

Hi Craig,

On Mon, Sep 15, 2014 at 1:40 PM, Craig Latta <[hidden email]> wrote:

> I don't think anybody ever even reported trying [Ffenestri].

     I did; it worked. And I just said so again a few messages ago. Hm.

OK.  It opens windows.  But a snippet in a workspace can do that.  It does not constitute a replacement for the current window system though does it?  But Vassili's work can be.  We had it in production at customer sites.  We could use it for development.  It was complete, in the sense that one could open arbitrary system windows as native windows, switch them back to "virtual" windows, snapshot etc and everything would keep working.  That's "working".  With great respect to Tim and John, their work in Ffenestri is not the same thing, is it?  By the same criteria I don't think what Qwaq did constituted a real system; it allowed the login WIndow to be displayed natively, but it didn't support development tools and it certainly didn't support snapshot or dynamic switching.  Being critical is not being insulting.  It's merely being objective.  At least I hope I'm being objective and not insulting anyone.  It is not my intent.

--
best,

Eliot

On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo
<[hidden email]> wrote:
> 2014-09-16 14:37 GMT-03:00 Sebastian Sastre <[hidden email]>:
>
>> Well, a while ago in the business list I’ve raised the idea that making
>> Pharo able to do native OS windows would help it to gain market space (as in
>> the opposite of staying at the margins of it).
>>
>> So, I’d be very positively curious about being able to use Pharo to do
>> multiplatform native apps
>
> The trend is shifting to mobile devices, iOS and Android are eating
> the whole market. So if it is about the potential market size, native
> mobile (tablets/phones/TVs) should come as the first option, before
> desktop.

+1.  Desktop apps are "dead" aren't they?  I'm doubtful that native
windows would help Smalltalk's popularity, as evidenced, I guess, by
the fact VA and VW have supported them for a long time; did they take
over the world yet?

> For development, native windows could prove very useful.

How so?  For me, one of the worst aspects of trying to develop in
VisualAge or VisualWorks *is* the multiple host windows.  It makes it
virtually impossible to work in more than one image, and reinforces
the "grand cathedral" thinking about Smalltalk; e.g. you're not
supposed to want or need anything outside your one, true, image.
Dinosaur!

I constantly work in multiple images, not only for separate projects
but for the ability to quickly and easily fork images for multicore
processing on the same project.  Other times simply to try something
temporary and possibly dangerous.  The memory isolation is critical
for productivity, the UI isolation for usability, and the multi-core
capability for performance.

I think we should focus on how to move to more and smaller
intercommunicating images rather than one big image.  I understand its
appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware
of any other use-cases where multiple host windows would be preferable
to one host window per image.

>> On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo
>> <[hidden email]> wrote:
>> > 2014-09-16 14:37 GMT-03:00 Sebastian Sastre
>> > <[hidden email]>:
>> >
>> >> Well, a while ago in the business list I’ve raised the idea that making
>> >> Pharo able to do native OS windows would help it to gain market space
>> >> (as in
>> >> the opposite of staying at the margins of it).
>> >>
>> >> So, I’d be very positively curious about being able to use Pharo to do
>> >> multiplatform native apps
>> >
>> > The trend is shifting to mobile devices, iOS and Android are eating
>> > the whole market. So if it is about the potential market size, native
>> > mobile (tablets/phones/TVs) should come as the first option, before
>> > desktop.
>>
>> +1.  Desktop apps are "dead" aren't they?  I'm doubtful that native
>> windows would help Smalltalk's popularity, as evidenced, I guess, by
>> the fact VA and VW have supported them for a long time; did they take
>> over the world yet?
>>
>> > For development, native windows could prove very useful.
>>
>> How so?  For me, one of the worst aspects of trying to develop in
>> VisualAge or VisualWorks *is* the multiple host windows.  It makes it
>> virtually impossible to work in more than one image, and reinforces
>> the "grand cathedral" thinking about Smalltalk; e.g. you're not
>> supposed to want or need anything outside your one, true, image.
>> Dinosaur!
>>
>> I constantly work in multiple images, not only for separate projects
>> but for the ability to quickly and easily fork images for multicore
>> processing on the same project.  Other times simply to try something
>> temporary and possibly dangerous.  The memory isolation is critical
>> for productivity, the UI isolation for usability, and the multi-core
>> capability for performance.
>>
>> I think we should focus on how to move to more and smaller
>> intercommunicating images rather than one big image.  I understand its
>> appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware
>> of any other use-cases where multiple host windows would be preferable
>> to one host window per image.
>
>
> That all makes sense from an experienced Smalltalker's POV.  But for people
> exploring the technology the lack of native windows is usually a huge
> turn-off and often reason to reject the technology.  The nice thing about
> Vassili's work is that it allows one to have *both*, without losing window
> state, and one can switch dynamically, and, IIRC, mix both, e.g. for
> development.  So it isn't an exclusive choice.

Ah, good.  Choice is good.  :)

> Re VisualWorks' support for native windows it was an essential component to
> VW staying in the market-place.  If it hadn't supported native windows it
> would have died the commercial death long ago.  Pre-web, one /had/ to have
> native windows for industry, and now with mobile native look and feel is
> even more important.  Further, VWs huge lack in its GUI was lack of support
> for native widgets.  We always used to tout MSWord's use of emulated widgets
> (apparently for performance reasons) as a defence but it didn't convince.
> The customer was always provided with poor emulations and a limited supply.
> IMO, native widgets would have made a big difference in hwo well-received VW
> was for GUI applications, where those using Windows could always turn to
> VSE.

Yes, I don't doubt that at all, especially during the time when
Windows NT / XP was the defacto platform one could expect anywhere and
everywhere.

I am curious now, however, in this technologically-splintered world
where Windows XP dying out, Windows 7 barely hanging on, everybody
hating Windows 8, and the promise of cheap upgrade to Windows 9, Plus
don't forget OSX widgets and then all the "widgets" people use on
their phones and tablets being basically different from app to app:
what IS "native" widgets these days? 

I wonder what those manager
folks who shunned the
non-native-but-perfectly-usable-and-in-some-cases-better widgets are
asking for now?   :)

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/

Eliot wrote:
>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?

Yes, wet's my appetite :)

Tiny means easy to download and use for scripting, no other dependencies
for the out of the box REPL experience. But still powerfull to built one on another
and scale up to large programs.

Initially you provide just a simple VM executable for a "tiny smalltalk" (ts), for simple
things like:

   c:\myscripts\ts.exe -e 3+4
   7

where ts.exe is the VM in a few kB including a small initial kernel image (as part of
the PE DATA section). It should be able to run scripts:

   c:\myscripst\ts.exe automate.st

It should be possible to easily build components (either with or without the sources):

   ts.exe sunit.st -o sunit.sll
   ts.exe sunit.st -noSource -o sunit.sll

So you can either include other scripts

   ts.exe -i sunit.st  mytests.st

or link the previously built binary components to form something new.

   ts.exe -l junit.sll mytests.st

But it should be possible to build another vm+image easily:

      ts.exe -i mykillerapp.st  -o killerapp.exe
 or   ts.exe -l mykillerapp.sll -o killerapp.exe

by writing a new PE file for Windows either including a new kernel image or a combined
one based on the already built-in initial kernel of the previous one.
So I can deploy a killerapp or reassemble it to form the next language version.

SmallScript was very close to that and it was a nice thing to work with.
Especially since usually Smalltalk usually throws things out at the end - but
one never builds a house by carving it out of a rock. We need bricks to assemble.

With the above scheme you could build components, some of them portable, others
explicitly non-portable as the code includes native calls. The later have to
be rebuilt on the other platform - so if you have good design abstractions you
can implement a UI lib on Windows and one on Mac.

Some of the components are with the source code packaged in for debugging
(but not changeable), for closed source components you leave it out.

And still it should support pinnable objects (not moved by GC for callouts),
sandboxing, Classes with UUIDs to allow for side by side loading/migration
and an extensible meta-scheme as this is where Smalltalk is still the hero of all
und metaprogramming will be our future.

Also the VM should be available as a shared component - so it can run in-process
in other programs like a web browser. Always wished to write:

   <script type="text/tinyscript">
         BrowserLog write: 'HelloWorld'.
   </script>

directly in HTML.

And this is only the beginning of the wish list...

>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

Yes, Fuel would be an option. At least it would be platform independent. Not sure
about other options (quick loading by mapping component using memory mapped files etc.)

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

For sure.

Bye
Torsten