On 12/4/08, Hans Breuer <[EMAIL PROTECTED]> wrote: > At 03.12.2008 19:33, Sameer Sahasrabuddhe wrote: > >> On 12/3/08, Sameer Sahasrabuddhe <[EMAIL PROTECTED]> 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/ _______________________________________________ dia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
