Re: handling properties of multiple objects

["Sameer Sahasrabuddhe" <sameerds gmail com>]

On 12/4/08, Hans Breuer <hans breuer org> wrote:

> At 03.12.2008 19:33, Sameer Sahasrabuddhe wrote:
>
> > On 12/3/08, Sameer Sahasrabuddhe <sameerds gmail com> wrote:
> > > Now here's a new way to track object copies, that tackles both these
> > > issues: instead of keeping a copy of the object in the dialog, we
> > > extend the property description itself, to carry a copy of the object
> > > from which it was derived. As a result, no matter how many objects are
> > > involved, only one object is used for updating the widget for each
> > > property.
> I'm still confused (not only by the term object not to be confused with
> DiaObject in your mail?) ;)

:) Sorry about that! I get carried away when mucking around waist-deep
in code at midnight!

> For Dia's property mechanism three classes are involved:
> - PropDescription: a constant instance just describing the type of ...
> - Property: initially created by copying it from the internal state of ...
> - DiaObject: a diagram element having multiple properties. They can be
>    modified by passing in a Property instance from where the respective
>    internal state in the object are adjusted.

Right. My fascination with the PropDescription comes from the problem
that I am trying to tackle ... that the properties dialog keeps a
private copy of the DiaObject and if this DiaObject is a group, it may
contain an arbitrarily large tree of DiaObjects within it. The purpose
of this private copy is merely to help update the property dialog
widgets when a property is applied, because it may have side-effects
on other properties. The properties dialog applies the property to
every DiaObject inside the private copy of the group. Since one
property is applicable to many DiaObjects within this tree, only one
of them is relevant. It is the last DiaObject from which the
side-effects are gathered.

Now we need a way to have as few DiaObjects in the private copy as
possible. This means that the private copies should be made when the
Property instances are created. But the Property instances are created
by a internal functions that never sees the relevant DiaObjects. But
the DiaObjects are available when the PropDescriptions are listed
together.

The PropDescription instances are global values and created only once,
and they are const, but I am making a case to make them mutable. They
are the most convenient place to hold the private copies. Dropping the
const-ness of the PropDescription is indeed a big change that needs
more justification. The other option is to somehow update a pointer in
the Property instance to record a private copy of the relevant
DiaObject.

Either way, these are big changes, and the resulting gain is not
terribly important right now. (The gain is that the property dialog
keeps a private copy of only a few objects, no matter how large is the
number of objects being changed simultaneously.)

> > I guess a new property dialog remains the only alternative. The memory
> > bloat involved with huge groups will have to be tackled when it does
> > actually become painful.
> That new diaog just needs to contain one vector of unique properties. This
> vector will get partially modified by the dialog and feeded into the
> various objects of the selection (or just one for the single selection
> case).

Yes. That's what I am going to do now. No more wild digressions.
Promise! :) Only thing is that I was talking about the private copy of
the selected DiaObjects that the property dialog keeps. The vector of
Property instances will be created in much the same way as the Dialog
for a single DiaObject.

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