Flexible squeak - a call for extension mechanisms

Daniel Vainsencher danielv at netvision.net.il
Mon Jul 14 12:34:50 UTC 2003


Hi everybody.

As we near the release of 3.6, and enter the planning stage for 3.7, I'd
like to offer a topic for rants, questions, ideas, designs and maybe
even code, in the hope some people will find it useful/interesting
enough to work on for 3.6.

The thing is that Squeak used to be a single system - whatever SqC
released. But it is fast becoming a flexible combination of a platform
(the image) that the community produces as a whole through the
harvesting process, and a sea of packages cataloged by SM. Except that
to be flexible, the system has to be "articulated" - the platform has to
have points of extension, hooks that the packages implement. 

The first such hook added to accomodate packages with SM was the dynamic
open menu, which allows applications to add themselves to it.

Now we also have a flaps registry, so that applications can easily add
themselves to the flaps.

To be precise, applications could always add themselves by simply
overriding the hardcoded description of the menu and so forth - the
point of registries is that they allow different applications to add
themselves simultanously without conflict.

Now Roel is working on a notification service that generates events when
code changes happen, so that applications interested in these events can
be added without mucking around the compiler and friends.

I thought I'd ask for other people to mention what other hooks they
think are needed, and mention some ideas I've seen floating around here
and there.

1. Keyboard shortcuts - these should be configurable by the user, but
should also be extendible by applications. For example, if someone comes
up with a local dictionary package, he should be able to expose that
function as a keyboard shortcut in text panes.
2. Menus in general - I think adding new registries for every menu that
needs it is lame. We should design a system that allows any application
to add to any (or almost any) menu dynamically. I think EMACS is
supposed to do something like this, though I'm not familiar with the
design.
3. UIs - Claus Gittinger, the author of Smalltalk/X, made a comment once
that having a GUI builder gives him a lot of leverage, because it
enables him to quickly implement UIs for any cool stuff he ports from
other Smalltalks. I think we need a UI builder for the same reasons, and
if the UI builder creates readable descriptions of the UI, it could also
let us write UIs that are common to MVC and Morphic (and whatever comes
next) just once. 

Any ideas on how to implement the above?
Ideas on other extension points that would clearly make it easier to
make packages first class citizens in Squeak?

Daniel



More information about the Squeak-dev mailing list