Re: properties dialog and grouped objects

["Sameer Sahasrabuddhe" <sameerds gmail com>]

Hi!

Continuing an old conversation ... I really hope the context is not
too hard to catch. Also posted some comments on the relevant bug. This
is mostly about modifying the _ObjectOps structure so that all Dia
objects have a new function that is used to apply properties to them.
This allows groups to support undo/redo for property changes
correctly, by defining a new class of Change objects.

On 8/4/07, Sameer Sahasrabuddhe <sameerds gmail com> wrote:

> > Just looked at the lst patch. It is changing every objects 'vtable'
> > and thus breaking binary compatibility. If necessary at all it should
> > be added at the end of the vtable (see objects.h struct
> > _ObjectOps) having only 4 unused left. Also one would need to
> >  implement a default handling for case where the objects function
> > pointer is NULL.
>
> Oops! I never realised I would have to take care of binary
> compatibility, I just inserted it into a place that "looks good" in
> the struct. Will fix it and upload another patch.

I have raised a question on whether binary compatibility should in
fact be broken in this case. More here:

http://bugzilla.gnome.org/show_bug.cgi?id=60331#c51

The correction required is very small in case we need to maintain
binary compatibility. Also default handling can be done easily for the
case where objects don't have a relevant function defined, but I would
frown on that too, since the default handler would not know how to
handle undo/redo for a complex derived object class. If the default
handler could do that, it would have been easy to do undo/redo for
groups without requiring this invasive change.

A related problem with group properties, is that the dialog box
becomes to large to handle. There was talk about reorganising
properties into separate tabs, but there is no scheme to categorise
them so far.

> > And (2) implies a need for a lot of reorganisation in properties.
> > Could you explain this a bit more. How could reorganizing
> > properties help to solve serious size restrictions?
>
> I can see one hierarchy to begin with:
> 1) Properties of identical objects
> 2) Common properties of objects that belong to the same sheet
> 3) Common standard properties
>
> If there was a way for recognising the properties of each objects like
> this, then the dialog box could provide separate tabs for this. That's
> the general idea of "reorganisation", although a lot more thought is
> required. Lars has said something similar in his reply already, where
> he mentions grouping the properties into "logical sets".

I have been looking at UML objects, and I realised that there are
multiple "property spaces" that are currently rolled into one. One
space is the "dia space", that includes properties relevant to drawing
a diagram ... borders, colours, fonts, etc. Another is "UML space"
that includes properties that are relevant to UML, but not directly to
diagrams ... class attributes, methods. In fact these in turn have
more properties such as private/public and visible or not.

There could be a heirarchy of property dialogs that are popped up from
parent dialogs. One could think of a dialog box that only shows "dia
space" properties, with a button that opens a dialog for "UML
properties" and so on. The functionality that I am trying to indicate
here, is this: how do you change a particular attribute "x" on
different classes in the diagram, from private to public, in a single
interaction?

Sameer.
-- 
Research Scholar, Department of CSE, IIT Bombay
http://www.it.iitb.ac.in/~sameerds/