Unified resizing API function -- Resizing group objects

[Grégoire Dooms <dooms info ucl ac be>]

Hello,
What about a standard  API function for the resizing of objects ?
Something like

// does a two way stretch on the object
objname_stretch(float x_stretch_offset, float x_scale, float 
y_stretch_offset, float y_scale)

This functions would be implemented in every object and would handle all 
resize operations.
x_stretch_offset is the x coordinate of the vertical axis not moving in 
the stretch
x_scale is the scale factor along the x axis
Similarly for y

objname_move_handle would call this function

For the box or image:
if the moving handle is N then
- y_scale would be the scaling factor determined by the Point to and the 
original poistion of the handle.
- y_stretch_offset would be the y coordinate of the S handle.
- x_scale is 1 and x_stretch_offset can be anything (i.e x coord of S 
handle)
if the moving handle is NW then {x,y}_stretch_offset are the coords of SE.
and the scaling factors are computed accordingly.

For the new resizing of the ellipse (center not moving) 
{x,y}_stretch_offset are the coords of its center.

with the opposite handle as the fixed_point (in the resizing profile of 
box or image) or with the center point (in the resizing profile of ellipse).

If a keep_aspect_ratio flag is set (either by the shift modifier as 
suggested in a previous mail and in the TODO file or by an attribute of 
the object) then both {x,y}_scale must be equal.

This function would enable an easy resizing of group objects :
- decide the resize policy ( == decide where the stretching axes are ) 
most probably the same as box (i.e. opposite handle)
- call the objname_stretch function with the same parameters on all 
objects of the group (possibly recursively on groups)

One should decide of the handling of keep_aspect ratio in group objects: 
either the presence of a "keep_aspect_ratio" object in a group makes 
the  group behave the same or the group can override that flag.

In case of rotations, either the stretch is done in the object 
coordinate set (this coordinate set is rotated and possibly translated 
wrt the world coordinates) or the stretch axes should be passed  as 
arguments. I personnaly prefer the first alternative as it is a simpler 
way of handling rotations and as I do not know of any applications of 
non-orthogonal axes for a two way stretch.

Any comments ?
--
Grégoire Dooms