On Sat, 23 Jan 1999, Alexander Larsson verbalised:
> 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?
register_object_menu(ObjectType, GtkItemFactoryEntry []);
The app would do this once for each object type. You're right, it does get
messy. But having the objects register menus is messy, too, I think.
>>> 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).
Ok, I'll see how it fits in.
>> 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.
You obviously haven't been reading alt.sysdamin.recovery:) All software
sucks, too. Of course,, some software sucks more than other.
>>> 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.
Actually, a thing like move-to-front should be on both. On the right menu,
it'd work on the selected object(s), on the middle menu just one the object
you're pointing at. I won't do any default items on the middle menu yet,
though.
>> 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.
True. So there won't be any accel-group for the middle menus.
>> 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.
Good.
-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
