On Sat, 23 Jan 1999, Alexander Larsson outgrape:
> On 23 Jan, Lars Clausen wrote:
>> It is, very close. I have made a registry, though it is based on the
>> ObjectType rather than Object, and allow the actual Object to give a
>> callback which can modify the menu (to, say, set toggles to correspond
>> to the settings of the object). I guess that's all in
>> get_object_menu().
>
> Ok, I've thought some more about this. I think i understand what you
> mean now.
>
> You've got a separate registry that maps ObjectType pointers to a
> callback which is called when the menu is pulled down. It can then
> modify the menu, both callbacks and active-state.
>
> I basically like it, except i think having a separate registry is bad.
> I'd rather have an new operation in ObjectOps. This saves a lot of code
> (you don't need to maintain the registry)
Well, there's not much to having a registry, it's something like 20 lines
of code.
> and it makes sure the
> interface between objects (which are the stuff that's in a diagram) and
> the app is well documented and visible.
That's the tricky point. Are these menus really part of the object
interface or of the application interface? To me, they seem to be
application-specific. The objects should not need to know about menus,
only about what operations can be performed on them.
> It's memory-saving too, there is
> only one ObjectOps structure per ObjectType, and I've already reserved
> 10 pointer values in it.
We'll save a hash table, it's true, but since the registry is based on the
ObjectType, we'll only have one entry in the registry per type, so the
memory saving is miniscule.
Hmmm... I don't think I like the idea of the right button menu changing
depending on where in a diagram you click it. It should be stable for the
diagram.
-Lars
--
Lars R. Clausen ([EMAIL PROTECTED])
A *real* smart bomb would call in sick, perhaps move to another country,
changing its name in the process, open a beach bar maybe and live out its
days in safe anonymity. -- Barry O'Neill in rhod
