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

[Hans Breuer <hans breuer org>]

At 26.11.2008 05:27, Sameer Sahasrabuddhe wrote:
> 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. 
I agree there could be a split, but I don't like to have two dialogs.
IMO a dedicated "style" property page (like I've done for UML Class) is ok.

But no matter if style or content the property must be available via the 
StdProps API. And the split should not force me to open another dialog just 
to switch between style and content editing.

> 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).
From my understanding this is just an implementation detail of 
PROP_TYPE_TEXT. We could as well allow to edit the text in the canvas _and_ 
the property dialog.

> 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.
Still bot convinced. Special purpose filtering is meant to be done via 
property flags like PROP_FLAG_VISIBLE, PROP_FLAG_DONT_MERGE, 
PROP_FLAG_NO_DEFAULTS etc.

> > > 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. 
We have discussed this some time ago. I'm still thinking there are better 
ways than just one arbitrary _static_ split. One old idea is giving the 
user the ability to choose between intersection and all properties.

> 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.
Yes, intersection ;)

> > 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
I'll try to look into it tomorrow.

Thanks,
        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert