Re: Group rotation
Re: Group rotation
- Subject: Re: Group rotation
- From: Gordon Apple <email@hidden>
- Date: Wed, 07 May 2008 12:31:19 -0500
This is a major advantage of separating the drawing (rendering) code
from the data model instead of having objects draw themselves (not to
mention cross-platform). Our renderer object is recursive (and could be a
shared object if not for the deficiencies in shadow rendering -- a story for
another time). When we replace objects with a group object, all the
transforms automatically work. Grouping can be nested to any level. Since
we only have one "Shape" type, groups can also take on object
characteristics such as fills, content, text, etc. This especially works
well for using group objects for sophisticated text containers where text
flows around contained objects.
I know that about every example of drawing has subclassed objects that
draw themselves. IMHO, that is the wrong approach. There are just too many
advantages to separating the object rendering and making it part of the C or
V part of MVC instead of the M.
> Implementing grouping that really works is quite hard.
>
> What about when groups are nested? This can go on indefinitely, so you
> need a mechanism that can take account of any number of nested groups.
> Since transforms from any level can be appended or prepended, this is
> the way to go I believe - each object has a transform that defines its
> position and rotation and size, and so does each group. When a shape
> is drawn it needs to apply all of the transforms for the whole group
> hierarchy that contains it. Also, when an object is grouped, it needs
> to have its coordinates translated so that they are relative to the
> group, (the series of transforms then compensates for this when the
> group draws its contents).
>
> When you ungroup, what about if you have now rotated and resized and
> some of the contained groups are also rotated and resized? The effect
> is that paths can get skewed, which is valid, but you need to preserve
> all of that when you ungroup. There's a lot more to it than meets the
> eye. Getting it right is hard. ;-)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden