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

["Young, Robert" <Robert Young dsto defence gov au>]

> Sameer Sahasrabuddhe wrote,  Wednesday, 26 November 2008 2:57 PM
> 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.

Sorry to butt in on the conversation, but it sounds to me like a
separation between "style" and "properties". Or "display style" and
"Object-specific data"?

I like the idea of separating all the objects "style" properties - it
allows for applying a consistent style to all objects - maybe in future
styles could be defined like in a word processor and then applied to
objects.

Rob.

IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the 
jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are 
requested to contact the sender and delete the email.