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
> 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 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?