Re: the UML ClassDialog v/s the generic Dia properties dialog

["Sameer Sahasrabuddhe" <sameerds gmail com>]

On 11/22/08, Hans Breuer <hans breuer org> wrote:

> > when a UML Class is double-clicked. Of all the things available on the
> > dialog, only three things are relevant to Dia, the diagram app:
> >
> > Text Color
> > Foreground Color
> > Background Color
> As Lars already mentioned this an arbitrary split. At least everything on
> the Style page is relevant (e.g. all these font sizes). But the same kind
> of "content" is available with many other objects (e.g. all the flow chart
> text). And as I said the split looks quite arbitrary.

Well, the point is to first agree that there is a split. Agreeing on
the where to put the split comes later when we actually get down to
implementing this. About other objects like the flow chart ones, that
is what I am saying too. The analogy that I wanted to draw is that the
text in the flow chart object (it's content) cannot be changed from
the (generic) properties dialog (there is no Flowchart Box Dialog, but
there could be one in principle, if we could justify such a thing).
This is the correct behaviour. There are some properties in each
object that are not relevant in a general context, and the widgets for
these should not be returned by functions like get_props() when
building the properties dialog.

> > 1) An "Edit" option in the context menu, that invokes the dialog.
> I don't think so, but maybe I still haven't understood what you want to
> accomplish with this split.

Yeah I agree with inertia about inserting items in the context menu.
There could be better ways to do this in the UI. The reason I want to
split is that when arbitrary objects are selected together and the
properties dialog is invoked, it should not overflow like it does
currently. The split is simple --- generic properties and specific
properties. When a user selects a flow chart box and a UML class, it
is better to show only properties that are mostly relevant, like line
colour, fill colour, font, etc rather than showing the whole horde of
UML properties.

> If the thing you want to address is the "multiple selection change" you may
> want to take a look at PROP_FLAG_DONT_MERGE ...

Ok. Havn't got around to doing that yet. The original reason I brought
this topic up (yet again) was that I wanted to fix the behaviour of
the OK button. I had reached a point where it seemed like a good thing
to split off the UML Class, but I managed to do that in a much simpler
way.

http://bugzilla.gnome.org/show_bug.cgi?id=488269

Sameer.
-- 
http://www.it.iitb.ac.in/~sameerds/