Flexible squeak - a call for extension mechanisms

Stephane Ducasse ducasse at iam.unibe.ch
Mon Jul 14 19:32:27 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.

Hi daniel

can we have as default preference browse with drag and drop in 3.6?

Stef

> 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