[squeak-dev] Re: Menu Registries

Hannes Hirzel hannes.hirzel at gmail.com
Fri May 14 19:38:37 UTC 2010


Steve Wessels wrote above

<citation>
Unifying the docking bar and world menu registry is a good idea and I
would like to see a uniform approach.  I'm frankly unattached to how
we do it just that we get over this and do it.  It's an old problem
with multiple solutions proposed in the past.  We should pick a
strategy and go forward.  And to further minimize churn I recommend
that if someone is going to write this code it should be stated here
and we can all evaluate it.
</citation>

I am not attached to a particular solution either.

Are there any news regarding a menu registry solution?
Is somebody of the commiters working on a solution?

--Hannes



On 4/30/10, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 4/29/2010 3:21 AM, Alain Plantec wrote:
>> Andreas Raab a écrit :
>>> On 4/28/2010 11:32 PM, Stéphane Ducasse wrote:
>>>> Good but what is your point?
>>>
>>> Compatibility and simplicity.
>> Come on Andreas, "simple" is not so much more precise than "cool"
>
> That comment deserves a more detailed exploration than I want to put
> into this message. You can find my response here:
>
> http://squeakingalong.wordpress.com/2010/04/30/measuring-simplicity/
>
>> and I don't think that having:
>>
>> ------------------
>> Editor class>>blinkingCursor
>> ^ BlinkingCursor ifNil: [ true ]
>>
>> EditorSetting class>>editorSettingsOn: aBuilder
>> <systemsettings>
>> (aBuilder setting: #blinkingCursor)
>> label:'Blinking Text Cursor')
>> parent: #Morphic;
>> target: Editor; description: 'When true, the text cursor will blink.'
>> -------------------
>>
>> is so much more "complicated" than
>>
>> -------------------
>> Editor class>>blinkingCursor
>> <preference: 'Blinking Text Cursor'
>> category: 'Morphic'
>> description: 'When true, the text cursor will blink.'
>> type: #Boolean>
>> ^ BlinkingCursor ifNil: [ true ]
>> -------------------
>
> You're right, by itself it may not be "so much more complicated". But
> isn't this forgetting a few things? Like for example, that not only are
> you adding the extra method, but also an extra class and an extra
> package? This gets you from a single entity (the domain code) to four
> entities (the domain code, the builder method, class and package). In
> terms of both conceptual and interface simplicity that seems significant
> (and a dozen of messages in the builder all add to interface complexity).
>
> BTW, I want to point out something important here. I'm not saying your
> approach is "bad". Good and bad, black and white, are not categories
> that I use for evaluating software design. I leave that to the people
> with overly simplified views on software development ;-) There are only
> different trade-offs for different goals. Your approach is perfectly
> reasonable for a given set of goals and trade-offs. If there is a need
> to have specific fine-grained control over the UI to particular
> preferences, I would choose precisely the same approach - make a package
> with views for the values that I want to modify. It's a perfectly fine
> approach for such a set of goals.
>
> Moreover, "simplicity" isn't an absolute attribute of software.
> Simplicity is a tradeoff. It is often worthwhile to trade off
> simplicity, for example when adding valuable new features.
>
> So my claim here is not about "good" and "bad". My claim is this:
>
> 1. The approach in Squeak is measurably simpler than yours. It may not
> fit your goals, you may need a different approach, that's quite
> possible. But there are numbers we can put on things to compare them and
> if we put the numbers on then Squeak's approach is simpler.
>
> 2. Because of the difference in interface complexity, I expect Squeak's
> approach will be easier to support in the long term. There's no proof
> for that, but I think the claim is valid, and I will watch the future
> developments in both Pharo and Squeak with interest.
>
> 3. Your initial design choice of using a builder framework for
> preferences implied the later complexity. Because the approach requires
> adding non-domain code to core classes it creates pressure to put this
> code elsewhere and to package that code separately. It's a valuable
> lesson about the impact of early design choices.
>
>> You prefer UI+domain mixing, we prefer UI separated from domain.
>
> I'm missing something. What UI+domain mixing? There is no UI code in
> Squeak's preference tags. There is only domain code and a method tag for
> discovery of the preference. Only Pharo has UI (builder) code; there is
> no equivalent in Squeak's preference tags.
>
>> And yes, the SettingBrowser implementation could be improved.
>> I know, but I'm happy because it can be removed or remade
>> without any other consequence.
>> And compare it to the PreferenceBrowser ...
>
> I'm not certain what your point here is. I'm only talking about
> preference declaration, not about how the preference browser functions.
> PreferenceBrowser itself is reloadable in Squeak 4.1 and one of the
> packages that I customarily unload for creating smaller images, because
> I'm quite happy to set my preferences by sending message to objects
> directly :-)
>
> Cheers,
>    - Andreas
>
>



More information about the Squeak-dev mailing list