Hello Squeakers,

IMHO, it doesn't make a lot of sense to think too much about making
Squeak the next great platform for word-processing, e-mailing, web
browsing and all those bread-and-butter applications - there are dozens
of stable, usable and mature applications for any conceivable operating
system out there. So why reinventing the wheel, just to reinvent it in
Smalltalk? Furthermore, I can't really see the point in having e.g.
Python available within Squeak. Why not just use CPython? Any reason?

When interoperability is the goal, XML-RPC (see www.xml-rpc.com) is IMO
a worthy goal to spend one's energy on. It's an extremely simple spec
for glueing net-wide distributed components together. For now, it's
implemented in Zope and Frontier, there are client libraries for any
web-relevant programming language (Perl, Python, Java etc.) and
Microsoft has adopted/embraced it as SOAP. It's much more important for
Squeak to speak interoperation protocols fluently - and XML-RPC has some
potential of becoming the base for a heavily service-oriented web.

Concerning Squeak's look and feel - the standard Morphic widgets
certainly won't win any 'beauty contest', and I think that the standard
Fonts supplied with the system are horrible to look at - especially the
omni-present Comic font. Well, but that's a matter of taste and
fortunately Squeak is so open that everyone with sufficient knowldge
(which is easily acquired) is able to customize his working environment
to a very high degree. Maybe the basic widgets (buttons, scrollbars,
lists, entry fields, option fields and so on) should be pluggable (or at
least their look).

I've extensively worked with a direct-manipulation interface before -
Gadgets for the Oberon System 3. In quite some respects, Morphic could
learn from it. However, I want to become more acquainted with this
framework first before outlining any directions (I plan to do a rather
detailed comparison of Squeak and OberonS3 at some undefined point in
the future, because there are so many striking similarities on the
surface and yet so many differences when it comes to implementation).
The most obvious one, however, is that complex Gadgets interfaces are
easily built 'by hand' and it's rather difficult/cumbersome to create
them programmatically (when compared to Morphic, at least). The
situation with Morphic, as far as I have experienced, is rather the
other way round. What lacks in the latter is an extremely simple
end-user-accessible scripting facility for glueing user interface
components together.

In Gadgets, for instance, UI components have an optional 'Name'
attribute (name resolution works bottom-up, if a referenced component
isn't found in a surrounding context [in Gadgets called Panel,
corresponds to a PasteUpMorph], it is searched for in the containing
context), and a 'Command' attribute, both easily accessible via the
Inspector.

Imagine a List gadget with a FileDirectory model (Name: fileList) and a
Button labelled 'Open' (doesn't need to be named) sitting on a Panel. To
make the Button open the selected document when clicked, its Command
attribute would have to be 'Desktops.OpenDoc &fileList.Value'. Simple
and effective, isn't it?

However, the Gadgets 'scripting' system isn't very sophisticated, but
for simple user interfaces (and most UIs are actually simple) just the
right thing to have. And I don't think it would be too hard to implement
it in Morphic - the PasteUpMorph would have to handle name lookup for
its submorphs (morphs could be bound to a specific PasteUpMorph just
like variables defined in Workspaces are bound to Workspaces. It should
be easily possible for the end-user to inspect the (message) interface
of a UI component. I imagine having a button telling an EllipseMorph
named 'emorph' 'emorph growBy: 10; moveBy: 20 at 0.'.

I certainly haven't grasped a (the) substantial amount of the current
end-user scripting efforts, but as promising and powerful as they look,
the system is also ... hm ... quite complex.

Stefan Matthias Aust wrote:
> If I only judge from the application level, I don't need Squeak.
Of course, Stefan, you're right - from this viewpoint, Squeak is not
really needed by anyone. Developing 'traditional applications' is nice,
but not necessary.

What it will shine in are the following areas:

- novel, highly interactive network-based applications. Swikis are
killers. Really.

- Squeak _is_ an excellent experimentation playground. And that's what I
always longed for. Not another FreeCell, although it's trÈs cool,
definitely ;-)

- Squeak _will_ be an excellent (media) fusion environment once we all
have 1 GHz machines. And this will happen anyway. So creating
easy-to-use new & active media authoring environments (to start with, a
simple drum box like Steinberg's BeatBox maybe, going up to the
integrate-it-all 3D, video, audio, SmallTalk programming combination)
should be a focus (it's mine, anyway ;-). The interesting problem is how
to maximize power and to minimize learning effort at the same time.
Immediacy, concreteness and coherency are key concepts in this area -
and Squeak (especially Morphic and Squeak-Alice are quite on the right
track, IMHO).

- In the future, when 3D interfaces on large walls become standard and
humans use natural communication means like talking and gestures to tell
objects what they want from them, object behaviour will be defined by
huge 'behaviour networks' with thousands if not millions of
interdependent rules (which need to be failure-safe and self-adaptive to
any environment) much more than a message protocol of 30 messages.
Squeak allows to quickly prototype faint images of this distant future.
Maybe it will evolve to the prime programming environment for this kind
of environments.

- simplicity. Squeak is actually a simple system a single human being
could possibly understand in almost all facets. The only other
environment (I know of) which allows this (at least theoretically) with
the same level of expressiveness and power is the Oberon System
(www.oberon.ethz.ch).

I love Squeak and the enthusiasm around it. Lack thereof (because of
constant grumbling about 'what needs/should/could be done, what
applications should be available, what isn't available, why people won't
use the system if no web browser is available' etc.etc. instead of
working on issues and realizing dreams have killed the Oberon System (or
rather the once vibrant community around it). I'm sure that won't happen
to the Squeak community, but people are encouraged to be constructive
instead of destructive/complaining. It's better for everyone.

What a tool can be used for is always much more interesting and
worthwhile to think about than what it can NOT be used for. Or at least
it should be.

Excuse the length of this mail. Hope I'll do better next time ;-)

Regards to everyone,

-- Chris

_________________________________________________
c h r i s langreiter - - - unterlangkampfen 3 2 7
f o r m  is function -- autriche 6322 langkampfen
0 0 4 3 / (0) 5 3 3 2 / 8 7 6 0 7 c a l l - n o w
w   w   w   .  l a n g r e i t e r  .   c   o   m

There are three kinds of lies:
lies, damn lies, and statistics.
--Benjamin Disraeli