Unified resizing API function -- Resizing group objects



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]