Menu bar (was: The Trunk: Morphic-kb.240.mcz)

On 20.11.2009, at 04:43, [hidden email] wrote:
Very neat! I like the menu bar :)

However, I'm wary of storing blocks in the menu items.

The canonical style is to store a receiver and a message, which leads to far less complications down the road. That's why in the menu item we have target, selector, and arguments instance variables, instead of a block.

Also, I'd rather move the updating behavior into the submenu itself. It doesn't really make sense to reserve an inst var in every menu item, plus a top-level menu might need updating too, not just a sub menu.

In fact, looking at it, I'm not the first with this idea :) There is an UpdatingMenuMorph for exactly that purpose.

- Bert -

Hi,
> However, I'm wary of storing blocks in the menu items.
>
> The canonical style is to store a receiver and a message, which leads to far less complications down the road. That's why in the menu item we have target, selector, and arguments instance variables, instead of a block.
Doesn't the new closure blocks mitigate those problems? Can you elaborate a bit?
Blocks are so much more convenient.

> Also, I'd rather move the updating behavior into the submenu itself. It doesn't really make sense to reserve an inst var in every menu item, plus a top-level menu might need updating too, not just a sub menu.
>
> In fact, looking at it, I'm not the first with this idea :) There is an UpdatingMenuMorph for exactly that purpose.
It don't think that this was its exact purpose, but I hijacked it:
Morphic-kb.242 in The Inbox.
What do you think?

Balázs

2009/11/20 Balázs Kósi <[hidden email]>:
> Hi,
>> However, I'm wary of storing blocks in the menu items.
>>
>> The canonical style is to store a receiver and a message, which leads to far less complications down the road. That's why in the menu item we have target, selector, and arguments instance variables, instead of a block.
> Doesn't the new closure blocks mitigate those problems? Can you elaborate a bit?
> Blocks are so much more convenient.
>
+1
the only problem with blocks, that they capturing all state (context,
receiver, temps etc), required to run. And you can't replace the
target as you may do it if action defined using message send..

Nonetheless, you still can mitigate these problems in blocks by using
message sends , like:

onClick:  [ self target buttonClicked]

instead of capturing target object directly:

onClick:  [ target buttonClicked]



--
Best regards,
Igor Stasenko AKA sig.

On 20.11.2009, at 14:41, Balázs Kósi wrote:
>
> Hi,
>> However, I'm wary of storing blocks in the menu items.
>>
>> The canonical style is to store a receiver and a message, which leads to far less complications down the road. That's why in the menu item we have target, selector, and arguments instance variables, instead of a block.
> Doesn't the new closure blocks mitigate those problems? Can you elaborate a bit?
> Blocks are so much more convenient.

The problem is that blocks are early-bound and opaque. You basically can't do anything with them except evaluating.

Here is what your updater block looks like in an Explorer:  




I see it is a closure, and I see where it was defined, but that's about it. I can't really change it without changing the code. Okay, I could replace it with a different block in an inspector (and then even its printed representation would be meaningless).

Where it gets really hairy is when blocks get stored on file and then read back. E.g., they refer to instance variables by index. When loading them back and the class was reshaped in the mean time, they refer to the wrong instance variable. And there is hardly anything you can do about it.

Now contrast this with this menu item:




It's blatantly obvious what happens, I see what it depends on, I can change it, serializing and reloading it is easy etc.

>> Also, I'd rather move the updating behavior into the submenu itself. It doesn't really make sense to reserve an inst var in every menu item, plus a top-level menu might need updating too, not just a sub menu.
>>
>> In fact, looking at it, I'm not the first with this idea :) There is an UpdatingMenuMorph for exactly that purpose.
> It don't think that this was its exact purpose, but I hijacked it:
> Morphic-kb.242 in The Inbox.
> What do you think?

Yes, I like that better.

- Bert -

Hi,
I fixed all the glitches I could find (Morphic-kb.244).
I'll continue with the contents. Suggestions are welcome.

Balázs

Finally had a chance to sit down and update a trunk image. The new top
menu looks fantastic!

On Sat, Nov 21, 2009 at 10:19 AM, Balázs Kósi <[hidden email]> wrote:
> Hi,
> I fixed all the glitches I could find (Morphic-kb.244).
> I'll continue with the contents. Suggestions are welcome.
>
> Balázs
>
>



--
Ron