Flexible squeak - a call for extension mechanisms

Stephane Ducasse ducasse at iam.unibe.ch
Thu Jul 17 09:12:29 UTC 2003


I agree daniel.

I think that having a way to describe where/with which other menu a 
menu would go
would be excellent.

Stef

On Tuesday, July 15, 2003, at 11:25 AM, Daniel Vainsencher wrote:

>> 	1. It's extremely easy to add registries when a need comes up.  Thus
>> there is no hurry to do it.
> But adding them individually right now means that code is repeated, and
> tricks are not shared. I think the open menu now sorts its entries. Are
> you sure the debugger registry do so too?
>
> Now that we have a couple of cases, and have learned from them, it 
> might
> be worth applying what we learned to a general system.
>
>> 	2. Registries remove the chance for a human touch, and leave things 
>> to
>> be organized by an algorithm.
> Except an algorithm can be guided by a human touch... Theres nothing
> preventing us from being a bit smarter about the orderings and 
> groupings
> possible, if we do it in one place. Do you want them sorted? do you 
> want
> the ability to specify that "this new menu item should be in the same
> group as that old one"? maybe you want the user to be able to reorder
> them as he wishes? all doable. First we need to decide what helps, and
> then put it in the menu extension mechanism.
>
>> 	3. Registries add inertia and make a lot of simple hacks more
>> complicated.  Any code touching the registryized part of the system,
>> must now work under more general assumptions.
> I agree we should not make everything extendible - the things I've
> mentioned are things that have caused me specifically some pain, and 
> I'm
> asking what things have hurt other people. And also I think we should
> have a wider vocabulary and smarter mechanisms for extension, that 
> cause
> less of the kind of pain you're talking about.
>
> Ideas?
>
> [something good about somewhat fixed keybindings]
> Ok, I think right now we're a little on the over rigid side here...
> remember that just because something is extendible doesn't mean that it
> *will* be changed all the time. EMACS is very extendible, but the
> important keybindings are so fixed other systems can have an "emacs key
> bindings" extension without embarrassing themselves...
>
> Daniel
>
> Lex Spoon <lex at cc.gatech.edu> wrote:
>> Bijan Parsia <bparsia at email.unc.edu> wrote:
>>> On Mon, 14 Jul 2003, Lex Spoon wrote:
>>>
>>>> IMHO, we should add hooks sparingly and as we need them.  We don't
>>>> really want everything to be customizable.
>>>
>>> Piffle. What "we" can you possibly be talking about
>>
>> We are all Borg.  The Bijan entity simply does not realize this yet.
>> Squeak and its users move forward as a unified whole, always taking 
>> the
>> most logical step and never disagreeing.
>>
>>
>>
>>>
>>> [snip]
>>>> I don't see a good case for extensible key strokes in the text 
>>>> editor.
>>>> There shouldn't be many extensions, because Squeak only has 
>>>> 1-character
>>>> key combinations.
>>>
>>> I've often wanted to change, augment, or override squeaks key 
>>> commands for
>>> specific projects/editors/etc. All the time, in fact. It's 
>>> horrifically
>>> painful as it stands.
>>
>> Okay, I'm with you, but there's a big difference between adding
>> keystrokes for your specific editor, and adding keystrokes system 
>> wide.
>>
>> Just consider: when you write your application, wouldn't you like to
>> know what keys are being used in the main, plain-vanilla text editor, 
>> so
>> that you don't hide a useful keystroke with one of your custom ones?
>> Well, if you'd like to know this, then there had better not be people
>> registering stuff in the system-wide keymap.
>>
>> Maybe I just misunderstand the proposal.  Having app-specific keymaps 
>> is
>> fine.  I wouldn't call that a registry, though.  Notice that the app
>> writer will know exactly what keys are bound to what.
>>
>>
>>>>  (Which seems fine, btw!  Do we really want multi-key
>>>> combinations in Squeak's text editor?!)
>>>
>>> Sure. Why not.
>>
>> Ack!!  Well, they take a long time to learn, and they're almost always
>> slower than menus.  They are a logical choice for emacs, but they seem
>> quite silly for a thoroughly graphical system like Squeak.
>>
>>
>>>> Let's be light on the hooks, *especially* in matters that pertain 
>>>> to the
>>>> user interface.  Generalization comes with a penalty.
>>>
>>> You've been pretty light on what the penalties could be, and pretty 
>>> strong
>>> on the idea that the only way to avoid them is to avoid improving 
>>> things
>>> on the programmatic side of things. I find this uncompelling.
>>>
>>
>> Let me tie it together better.  Notice the following:
>>
>> 	1. It's extremely easy to add registries when a need comes up.  Thus
>> there is no hurry to do it.
>>
>> 	2. Registries remove the chance for a human touch, and leave things 
>> to
>> be organized by an algorithm.
>>
>> 	3. Registries add inertia and make a lot of simple hacks more
>> complicated.  Any code touching the registryized part of the system,
>> must now work under more general assumptions.
>>
>> Thus, registries add a moderate amount of definite badness, and 
>> putting
>> them off costs nothing.
>>
>>
>> I guess in general you could sum up my stance as anti-flexible Squeak.
>> :)  Don't get me wrong -- I'm glad that the sticky parts *are* getting
>> greased, in particular the open menu and some of the flaps.  But I 
>> want
>> the main Squeak release to only have generalizations that will 
>> actually
>> be useful.  Besides, it is good to put our feet down about a decision
>> every once in a while.  If we aren't going to make any decisions about
>> what goes into Squeak, then why don't we just give up and release an
>> empty file to the world?  Everyone can fill in the file with whatever
>> they want.
>>
>> 	http://c2.com/cgi/wiki?PrematureGeneralization
>>
>>
>> Lex
>



More information about the Squeak-dev mailing list