Re: parenting (patch)

[Lars Clausen <lrclause cs uiuc edu>]

On 27 Jun 2003, Vadim Berezniker wrote:
> This is a patch for the idea that I mentioned a bit ago.
>
> I need it for the stuff I'm working on... I just dived into the dia
> code, so I may not have had the best knowledge of the internals.
> I'll be glad to make any changes that are required ...

I didn't reply to this, but as you may have noticed, it has been applied.
I've also added undo.

> If you wanna play around with this, apply the patch, then edit
> objects/standard/box.c and change "BOX_CAN_PARENT FALSE" to
> "BOX_CAN_PARENT_TRUE" and recompile. From that point, you'll be able
> to add children to any box object.

I removed this, and instead put parenting permanently on UML Large
Package.  I'd like syggestions for what else should by default be able to
parent. 

> I'm also including 2 sample (silly) diagrams that make use of
> parenting for no reason whatsoever :)
>
> Here's a summary of this... (if it's turned on)
> * An object can have a parent object, and can have many children.
> * Dragging a tool onto an existing object makes the dropped object a
> child of the existing object at that point.
> * The created object using drag'n'drop is limited to within the parent.
> If it's bigger in any dimension, that dimension is sized down to fit.
> If there's no way it can fit, an error message is presented and the
> object is not created.

That check doesn't seem to work, I can create things that are half-on,
half-off a parent.  It may be a good idea to try to move it to wholly
within the parent.

> * Creating an object by selecting a tool and dragging inside the
> diagram will make the new object a child if the upper left corner is
> within another object
> * Creating via this method is also limited to within the parent
> (i.e. you can't drag beyond the parent)

That works nicely.

> A lot of the things that a "Group" is used for can be done with
> parenting. Some even better. e.g. you can create a big square with 9
> squares within it aranged in a 3 x 3 formation. You can drag the main
> square around automatically moving the children. Then, you can
> individually move each square (and any children it might have) without
> having to "break the group."

I'd like to have group be implemented with parenting -- groups are a
strange hack right now.  It'd require that the children cannot be
selected, but is otherwise just an invisible object.

> Note #1: I changed the g_new() call to g_new0() during group
> creation. I mention this because it's not exactly relevant to
> parenting work. (It just caused a side-effect which I had to
> fix). Some fields might not have been reset to 0 and left with junk.

It's overall better to use g_new0, except for time-critical code where you
know you're filling in all the fields.

> Note #2: When you perform "Copy" on selected objects, a copy of the
> list is made. When you perform "Paste" yet another copy is
> performed. Is that intentional or is that a bug?

That is intentional.  In case the originals are changed, we need the list
copy, and in case of multiple pastings, they shouldn't share lists.

> Question: How can I determine the order in which the objects are
> present ? i.e. let's say I draw a square, then a square within a
> square, etc. Each new square will be "above" the previous squares. I
> didn't see any z-order code or anything like that during creation of
> objects. I need this to fix a small problem with using the "Parent"
> menu command. (Not critical, just an annoyance).

The z-order is implicit in the order in the list.  Thus, to do Bring Object
to Front, you essentially do g_list_remove followed by g_list_prepend.

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| HÃrdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?