Group objects

[GoogleCodeExporter]

Add ability to group and ungroup objects.

Original issue reported on code.google.com by rusn...@gmail.com on 22 Jun 2009 at 2:23

• Blocking: #73, #201

[GoogleCodeExporter]

This is dependent upon implementing issue 31

Original comment by codedr...@gmail.com on 22 Jun 2009 at 2:28

[GoogleCodeExporter]

Original comment by codedr...@gmail.com on 9 Jul 2009 at 7:59

• Added labels: NeededFor-2.3
• Removed labels: NeededFor-Future

[GoogleCodeExporter]

So now that multiselect is supported, how would grouping work:

1) add group button to the multiselect context tool area

2) create a group context tool area with one button:  ungroup

3) when group is clicked, then a new group element is created (with new id) and 
all
selected elements are made part of the group, the selected elements are 
unselected
and the group is selected

4) when a group is selected, fill and stroke will not be editable

5) for this initial version, resizing is not supported on groups (just like 
text)

6) for dragging a group nothing needs to change for mousemove, but for mouseup 
we
need to think.  I see two options:

a) when mouseup keep the transform on the group and leave the child elements as 
is
(this probably makes the most sense).  only issue is making sure the group's
transform is parsed properly on mousedown OR

b) when mouseup, need to iterate through all children of the group and apply the
movement individually (and remove the transform on the group)

Original comment by codedr...@gmail.com on 9 Jul 2009 at 8:05

[GoogleCodeExporter]

NOTE: the issue with 6a or 6b comes down to ungrouping.  

If we went with 6a, when ungroup is clicked then we have to manually move the 
child
elements at that moment (which means parsing the transform attribute on the 
group
anyway).

If we went with 6b, when ungroup is clicked then we don't need to do anything 
but
remove children from the group and delete the group.

Original comment by codedr...@gmail.com on 9 Jul 2009 at 8:07

[GoogleCodeExporter]

I guess I'm favoring 6a.

One more requirement:

7) when delete is clicked for a group, all child elements of the group must 
also be
deleted

Original comment by codedr...@gmail.com on 9 Jul 2009 at 8:10

[GoogleCodeExporter]

Moving this out to 2.4 as I don't think I'll have time to work on it

Original comment by codedr...@gmail.com on 14 Aug 2009 at 3:34

• Added labels: NeededFor-2.4
• Removed labels: NeededFor-2.3

[GoogleCodeExporter]

8) when ungrouping, ensure all elements are positioned correctly, this will 
depending
on how reqt 6 is handled:
   if we go with option a (use transform on the group) then upon ungrouping we need
to manually move/scale/rotate all elements in the group to their current 
location
   - if we go with option b (modify all elements of a group when moving, etc) then
upon ungrouping we need to do nothing but delete the group element

9) add group and its attributes (id, transform?) to the whitelist

Original comment by codedr...@gmail.com on 17 Aug 2009 at 7:13

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by adeve...@gmail.com on 25 Aug 2009 at 11:30

• Added labels: Element-Support

[GoogleCodeExporter]

Issue 174 has been merged into this issue.

Original comment by codedr...@gmail.com on 4 Sep 2009 at 1:46

[GoogleCodeExporter]

Issue 173 has been merged into this issue.

Original comment by codedr...@gmail.com on 4 Sep 2009 at 1:46

[GoogleCodeExporter]

I'll take this issue up and start picking away at it on the trunk

Original comment by codedr...@gmail.com on 4 Sep 2009 at 9:44

• Changed state: Started

[GoogleCodeExporter]

Original comment by codedr...@gmail.com on 4 Sep 2009 at 9:44

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

Requirements 1-4 implemented as of r601.

Original comment by codedr...@gmail.com on 5 Sep 2009 at 10:10

[GoogleCodeExporter]

Two known problems as of r604 with the group/ungroup all dealing with rotations:

1) group elements, rotate the group, drag-move the group, undo, redo
2) group elements, rotate the group, ungroup

Original comment by codedr...@gmail.com on 6 Sep 2009 at 3:30

[GoogleCodeExporter]

r605 fixed the first problem, r606 fixed the second problem.

Known problem now are, if any child elements of a group are themselves rotated:

3) resizing the group causes problems
4) ungrouping causes problems

Original comment by codedr...@gmail.com on 6 Sep 2009 at 1:05

[GoogleCodeExporter]

Just as a reminder:
at r608, I see two small problems after resizing, apart the problems in the 
group itself:

1) Freehand line and Straight line switch to No fill and No stroke if you draw 
them
just after resizing a group
- Draw several Objects / Group them / Resize the group / Select Freehand or 
Straight/
Draw a line ---> Fill and stroke are switched to none, and the drawn line is 
invisible. 
Sometimes, but it's hard to reproduce, the line will jump at the very top of the
canvas, and will have "NaN" in x2 and y2 value.

2) Polyline Fill and Stroke both switch to solid black if you draw a polyline 
just
after resizing a group
- Draw several Objects / Group them / Resize the group / Select Polyline/ Draw a
polyline ---> Fill and stroke are switched to solid black. 

Original comment by worms_...@yahoo.com on 7 Sep 2009 at 7:38

[GoogleCodeExporter]

This is a proposal for new icons for shape_group.png and shape_ungroup.png
After using the current ones, I really feel they look too much the same, and if 
it
hard to know which is which at first sight.

The proposed ones are far from perfect, but I feel they are more different from 
one
another, so easier to recognize.
They would need polishing and all suggestions are welcome. SVG files, other 
sizes...,
at your disposal.

http://www.corpsmoderne.net/~eve97/vertex/svg-edit/group_icon_4_arrows_3_16.png
http://www.corpsmoderne.net/~eve97/vertex/svg-edit/ungroup_icon_4_arrows_3_16.pn
g

Original comment by worms_...@yahoo.com on 7 Sep 2009 at 11:36

[GoogleCodeExporter]

I'm not rejecting your artwork, thank you!  However, I do want to point out 
that's ok
if the icons look similar (in fact there's some benefit in making them look 
like they
belong to the same family so the user knows the general function).  

Because here's the point:  The two icons will never appear in the same toolbar. 
 If
you've selected multiple things, then the Group icon will only be visible.  If 
you've
selected only one group, then only the Ungroup icon will be visible.

Original comment by codedr...@gmail.com on 8 Sep 2009 at 1:59

[GoogleCodeExporter]

I do agree... you don't see the two icons at the same time. 

The problem is that I (personally), become a bit "silly" with icons. 
I view an icon a few times, it's tiny, it's blue, then it must be the Group 
icon. I
don't even "think" when I view the icon.

So, if another icon looks almost the same, and is also blue (in our case), I'll
_always_ think it's the Group icon, although of course, it can be, because I'm 
not
currently grouping things. Or am I? :-)

I'm more confused and it makes me need to stop drawing, and to start 
wondering... and
it's a loss of time :-)

(P.S.: This is also why I don't like the Tango icons, generally speaking: they 
all
pretty much look the same, I'm never sure I hit the right one).

Original comment by worms_...@yahoo.com on 9 Sep 2009 at 10:38

[GoogleCodeExporter]

I have some fundamental issues in trying to deal with grouping, I will try to 
air
them here to illicit feedback:

1) Open up a new document Google Docs and Insert a Drawing
2) Open up a new document in Inkscape
3) Open up a new document in Adobe Illustrator

Now in all tools:

- create a rect, rotate it 45 degrees
- create an ellipse, rotate it -45 degrees
- group the rect and ellipse together
- stretch the group horizontally by at least double the original group's width
- ungroup

Here's what we can notice:

- in all cases, the rect is no longer a rectangle, because of the non-uniform 
scale
on a rotated axes, it has become a parallelogram
- Google Doc's selector box has also become a parallelogram (seems quite odd),
GoogleDocs.png
- Inkscape's selector boxes are ALWAYS aligned to the window, not the object,
inkscape.png
- Adobe Illustrator's selector box for the rect is rotated 45 degrees, yet is 
still
rectangular, AI.png

I guess the question comes down to:  when a shape can no longer maintain its 
original
geometry (a rect no longer looks like a rect), what should we do:

- do we keep it a rect and apply a transform="translate(cx,cy) scale(sx,sy)
translate(-cx,-cy) rotate(angle,cx,cy)" or do we convert the rect into a path 
and
just change the points?
- how do we deal with a selector box for a rectangular manipulated as above?

It's interesting that three different tools do it three different ways.  
Inkscape's
method is the way we started doing selector boxes, but then I changed that in 
2.3
when I introduced rotations.  Google Docs seems the most weird (a parallelogram 
for a
selector box), so I guess that leaves Adobe Illustrator behavior?

Original comment by codedr...@gmail.com on 11 Sep 2009 at 2:11

Attachments:

• GoogleDocs.png
• inkscape.png
• AI.png

[GoogleCodeExporter]

As far as I am concerned, the AI solution for rotating the bounding box leaves 
me...
very, very confused. What will happen if I drag a corner grip, I have no idea. 
It's
too much to skew AND to rotate in the same "operation", I think.

The Google Doc screenshot is odd, too. Why is the rotation handle "skewed" to 
the
left?...

To the question of "do we keep it a rectangle or do we convert it into a path", 
I
would say that it should be kept a rectangle, because a rectangle can have 
rounded
corners, which also you would need to keep, I think. 
Converted into a path, it would then be impossible to get "perfect" (skewed, 
rotated)
rounded corners if ever you wanted to modify the rounding value?

I'm not sure I understand completely the meaning and implications of this, nor
whether the following will answer the questions, but what would make sense to 
me is:

- The bounding box of an individual object is right next to the object (as what
happens now for a rectangle), so it rotates with the object.

- The bounding box of a group includes all the objects, and takes the form of a
rectangle.

- Rotating, skewing, resizing in any direction, applies to the whole group, not 
to
individual objects. (We do not have this option yet, if we ever will have it).
So it's perfectly understandable that if you resize a group in one direction 
only,
the shapes change. But a rectangle still has to stay a rectangle, to keep the 
rounded
corners.

- Once ungrouped, the position of the bounding box should be the same as if the
object was not grouped then ungrouped, that is, still "near" the object.

Does this make sense?

(More to come, maybe...)

Original comment by worms_...@yahoo.com on 11 Sep 2009 at 7:59

[GoogleCodeExporter]

-- we keep it a rect and apply a transform="translate(cx,cy) scale(sx,sy)
translate(-cx,-cy) rotate(angle,cx,cy)" on whole group. It is better way.
-- While ungroup we can apply same transform on individual objects.

Original comment by narendra.sisodiya on 11 Sep 2009 at 9:54

[GoogleCodeExporter]

Thanks both - I agree we should try to keep it as a rect with some transforms.  
Btw
wormsxulla, the rounded corners on a rect would still be maintained if we 
converted
it to a path.

As far the selector box on shapes that are rotated and then stretched along a
different axis, I wasn't clear on wormsxulla's answer since she didn't like AI 
or
Google Docs solutions and Inkscape's is out of the question since we rotate our
selector boxes.

Personally I'm preferring the AI option (the selector box is rotated with the 
shape
but stays rectangular).  As for the corner grips, it would do the same thing it
always does:  it changes the rectangular bounding box of the shape and the 
shape is
then proportionally fit into the new bounding box.

Original comment by codedr...@gmail.com on 11 Sep 2009 at 12:11

[GoogleCodeExporter]

Re. the rounded corners, I meant that, yes, you would visually still have them 
in the
path, but wouldn't be able to change them with the "rounded corners" option, 
which is
what, in my opinion, is the problem.

For the rest, I'll re-think about it :-)

Original comment by worms_...@yahoo.com on 11 Sep 2009 at 5:28

[GoogleCodeExporter]

wormsxulla - you have a good point, thanks for clarifying

Original comment by codedr...@gmail.com on 11 Sep 2009 at 6:11

[GoogleCodeExporter]

Going to close this issue as of r633.  Resizing groups will be handled as part 
of
Issue 201.

Original comment by codedr...@gmail.com on 13 Sep 2009 at 3:51

• Changed state: Fixed

[GoogleCodeExporter]

Re. the bounding box, I found this thread which maybe is of interest:

http://www.inkscapeforum.com/viewtopic.php?f=28&t=3202&p=14950&sid=b3244266a675f
055c62bf08af92c995b#p14950

Original comment by worms_...@yahoo.com on 14 Sep 2009 at 8:45

[GoogleCodeExporter]

regarding bounding box, my opinion:

-AI is the way to go
-bounding box for any group should have the same behaviour as bounding box for
individual object:
-initial rectangle with angling = 0
-same kind of control areas for rotate and resize

Original comment by Christia...@gmail.com on 14 Sep 2009 at 2:06