Re: Setting the properties of multiple selected objects in steadof just one (the first or only selected->data)

[Philip Van Hoof <spamfrommailing freax org>]

On Thu, 2005-01-13 at 15:34 +0100, Lars Clausen wrote:
> Philip Van Hoof sagde:

> > o. I'd prefer a better menu-structure and a distinction between
> > "Selected objects" and "Currently selected object". Right now the menu
> > says "Objects". Whereas the properties dialog-box is using " Currently
> > selected object". I'd be better if there would be two menu's. One for
> > "Currently selected object" and one for "All selected objects".

> I don't know that there's much use for a "Currently selected object" as
> such, except perhaps for the middle-mouse-button menu.


> > o. A group-object inherits from object. Therefor it's possible to
> > overwrite the get_properties and apply_properties functions (they are
> > luckily functionpointers. I just hope that the function pointers are
> > using consistently in stead of the implementations for them. In which
> > case overwriting by just letting the functionpointer point to another
> > function for group-objects, is possible). I have plans to do so and to
> > implement a get_properties and a apply_properties for group-objects.

> Once we have properties setting on selected objects working, we can remove
> that crap from the group object.  Never was a good model.  Groups should
> indeed inherit from object, and might (at some point) be changed to look
> like parenting.  This is not something that should hold up the
> selected-objects properties code, though.

Should it be possible to set all the properties of individual objects in
a group? In which case I think only a treeview of properties is going to
give it a usable userinterface (so rewriting the entire properties-gui).

Or does setting the properties of a group-object basically means setting
the changed values (in the dialogbox) of as much individual objects of
that group-object to the new value. So in that case the dialogbox needs
an union of properties of all individual objects.

> > o. The undo/redo stuff will right now undo/redo the actions per object
> > that had been selected when we applied the properties. It won't undo the
> > whole set of actions in one time whereas the apply-button of the dialog
> > box does apply all properties in one time (for the end-user point of
> > view, that is). I'm not sure how to solve this. It might involve
> > altering the undo/redo code (making it possible to pack a set of
> > historical actions together or flagging actions to belong in a group
> > that is atomic and thus needs to be undone in group rather than
> > individually).
> 
> Check out the transaction points, sounds like what you're talking about.

Perhaps. I haven't yet checked it out. Will do.

> > o. Comments and suggestions about this feature from users who have
> > actually tested it.

> I applied and it compiled nicely.  I saw two bugs (trying to use it with
> boxes, ellipses and polygons):

> 1) The properties were duplicated, i.e. twice as many properties were
> shown in the dialog box that there should have been.  First set seemed to
> apply to all objects, though.

Yes. I've quickly walked through the code that detects intersections. It
looks like it's checking whether or not the function-pointer of the
apply-handler is already used in one of the other already stored
properties. Or something like that. If thats correct, I'm guessing the
problem is that for the user it's the same properties, but they have
different apply-handlers (so in reality they're different). But I can be
wrong here, I haven't really investigated that intersection-function
very deeply. So far I Just assumed it's functionality is what I need
(but perhaps thats untrue).

> 2) Pressing Apply applied all properties to all objects, not just the
> changed properties to all objects (FYI, that was the stage I got to in my
> attempt for groups a while ago:)

To get the working correctly, we first need to show the user that he has
changed a property. For example by doing something with the color. Then
we will need to alter the functionality for applying properties to an
object. Perhaps a flag in the struct of a property (gboolean changed)
and letting the GUI set that flag. And letting the apply-handler check
for it. Something like that . . .

I perhaps misunderstood the 'checkboxes' story of Hans. If this is what
he ment, it's indeed necessary to have something like it. I don't feel,
however, a checkbox next to each property is going to make the user
understand what happened and/or what is going to happen. Delphi, I
remember,  and Visual Studio .NET, will bold/unbold the value-label of
changed properties.

For example:

Unchanged:
Font: Luxi whatever
Color: Blue [ABLUECOLOR]

Changed:
Font: <b>Luxi whatever</b>
Color: <b>Blue</a> [ABLUECOLOR]


> > Short: It's all possible. However. So far I haven't received many
> > feedback from the core developers of Dia. Currently I am waiting for
> > that interrupt to be set, by them, with perhaps instructions and
> > thoughts, from them, on the mailinglist of Dia :-).

> Here you go!

Ah, oeps :-). I wasn't aware that you're the Lars from the authors.h
file! In that case I've indeed just received that interrupt.


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org