On 6 Jun 1999, Lars R.Clausen wrote:
> On Fri, 4 Jun 1999, [EMAIL PROTECTED] wrote:
>
> Ok, that sounds fair. There are actually several different combinations
> you might want:
>
> 1) Affect this object only
> 2) Affect all selected objects of this kind
> 3) Affect all selected objects
> 4) Affect all selected objects of this kind with the same setting
> 5) Affect all selected objects with the same setting
>
> I tried a simple hack that would do (2)[1], and now I'm beginning to see
> the problems (which actually seem to tie in with the undo functionality).
> First off, applying the properties don't just set the property that is
> changed, but all of them. So if you have a group of objects with mixed
> properties, doing a group set will force them all to have the same
> properties. Second, there is no (easy) way to do (3) and (5), since you
> can't tell if other kinds of objects have the equivalent properties.
> So we would like a more abstract way of handling properties, something like
> each object having a list of 'known' properties. That way, we could
> generate the properties dialogues from that list rather than (as now)
> having to do it for each object, and we can ask each selected object if it
> has the property we are setting. Also, setting a property becomes easier
> to remember for the undo function.
>
> Alexander, what thoughts have you made about the undo functionality? I
> could see how the properties settings would be one of the more difficult
> parts of that.
>
Yes, I played around with properties.c and everything was cool, except it
changed ALL the values of all selected objects. What really needs to
happen is a copy of all selected objects needs to be stored when the
properties dialog comes up (because you can go back and deselect/select
things after the dialog is up). there is the 'line' variable in
LinePropertiesDialog which represents the last thing selected. That seems
fair enough...Just compare the 'line' arguement of
line_apply_properties(Line *line) to values in
line_properties_dialog->line and there's your list of values that changed.
However you need a g_list of selected items from when the dialog was
brought up (easy enough, except what if the items have since been
deleted?).
What would be nice for 3 and 5 is if properties were stored as key/value
pairs (or better yet just had a mechanism to refer to them as such). That
way you could say something like: (Note: this code does not resemble
anything in Dia, it's merely for example)
if (color=obj->get_value("color")) {
if (color==origcolor)
obj->set_value("color",newcolor);
}
So as long as the property "keys" were the same accross objects
everything is peachy. Of course it would require coding get_value() and
set_value() for each object that has properties. This would probably be a
big proposition, and there is still the matter of how the user selects
from this multitude of options for setting properties.
I for one would be happy just to get single-type settings done for now.
