On 23 Jan, Lars Clausen wrote:
> Well, there's not much to having a registry, it's something like 20 lines
> of code.
How does an object register itself in this registry?
>> 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.
I'm pretty pragmatic about these things. There has to be a way for the
app to get a pointer to a function that knows about menus. Whichever
way you get it the object must know about menus, so i feel the already
existing way is more natural. This is quite like the way the
properties dialog works now (with get_properties and apply_properties).
> True, they're better than most machines. But all hardware sucks.
All hardware? Isn't that a little hard. Kinda hard doing software
without any. Programming turing machines isn't all that fun.
>> Or another idea. Why not have both in the right mouse-button menu.
>> Separated by a separator. That's how Visio does it i think.
>
> There are arguments both for and against:
> One menu means you won't have to think about which menu an operation is in,
> and people will see the operations when they see the right-button menu
> (which most should be used to from Gimp).
> Two menus means there will be a 'general' menu that you can get anywhere,
> and a 'specific' menu that is based on the object. It also means that the
> object operations will be more accessible, since there won't be as many
> menu points to traverse. Also, we won't have to make the general menu know
> about the clicked point, which is necessary for the object menu.
Ok, i think i agree with you. Middle button is the object specific
menu.Right button the general. I don't know if there should be any
default items in the object menu though. If there were, say
move-to-front, should it work on that object only, or (as the one int
the right menu) on all selected objects.
> A separate problem is the keyboard shortcuts. Should the active object
> determine which shortcuts are available? What about the click point?
I feel that keyboard shortcuts in the object menu, which changes with
time and mouse-position, would be confusing. Better to not have any.
Dia isn't really usable without mouse anyway.
> We could have both, you know. Just append the object menu to the general
> menu, but still bind it on the middle button. We would still have to
> consider the click point for the general menu, though.
>
> 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.
Agreed, non-changing right button menu.
/ Alex
