TIP #164: Add Rotate Subcommand to the Canvas Widget

TIP:	164
Title:	Add Rotate Subcommand to the Canvas Widget
Version:	$Revision: 1.5 $
Authors:	Arjen Markus <arjen dot markus at wldelft dot nl> Dimitrios Zachariadis <dzach at hol dot gr> Donal K. Fellows <donal dot k dot fellows at manchester dot ac dot uk>
State:	Draft
Type:	Project
Tcl-Version:	8.7
Vote:	Pending
Created:	Monday, 17 November 2003
Keywords:	Tk, canvas

Please enter your e-mail address (required), your name (optional), make your edits to this TIP and its Abstract, and Submit them. See TIP 3 for a description of the TIP format.

You are advised to copy the text of the TIP into an editor, make your edits there, and then paste back.

E-mail:
Name:

Abstract:	This TIP proposes to add a ''rotate'' subcommand to the canvas widget to facilitate rotating items in very much the same way as is now possible with scaling and moving.
Body:	~ Rationale The canvas currently allows a programmer to scale and move items, but the third common affine transformation, rotation, is not supported. This can in itself be simulated by a script (simply get the coordinates of all items involved, transform them and set the new coordinates), but if you have several hundreds or even thousands of items this gets very slow. Rotation is easy for polygons and lines: simply transform the coordinates. For circles and circular arcs new bounding boxes must be calculated and in addition for arcs the starting angle must be changed. Implementing rotation should consider what to do with items that can not (easily) be rotated: text items, rectangles, non-circular ovals and arcs, widgets and images. Currently, text can not be drawn at an arbitrary angle, so I propose to only transform the coordinates at which the text is "anchored". A similar strategy can be used for widgets and images. For rectangles and general ovals and arcs there are two choices: * Transforming the item into a polygon would solve the definition problem (these items are defined by a bounding box and the orientation is implicitly assumed), but might break scripts that look for a particular type of item. * Therefore we will simply calculate a new bounding box and ''ignore changes in orientation''. ~ Proposal Canvases will have a new subcommand, '''rotate''', which will rotate the coordinates of chosen items by a specified angle about a specified point. > ''canvas'' '''rotate''' ''itemOrTag'' ''x'' ''y'' ''angle'' Note that most of the arguments are very similar to the canvas's '''scale''' subcommand. ''Angle'' is measured in degrees, with positive values indicating anti-clockwise rotation. ~~ Canvas Item C API Alterations [[These are required for this TIP, but are not yet done.]] ~ Reference Implementation A reference implementation does ''not'' yet exist. ~ Future Work Should we also consider the possibility of reflections in a line? Should we also consider more general linear transformations (to be specified via a 2x2 matrix)? What about full affine transformations (i.e. with the translation components)? If we implement these from the start, we need to do only a little more work. ~ Comments It might be useful to utilize the -anchor Tk option in all canvas items and add a new "-anchoroffset $x,$y" option, where $x $y be canvas distances relevant to the anchor position. Once defined, or with their default values, the -anchor and -anchoroffset values combined will provide the item's center, for placement and rotation purposes. Item sets, constituting symbols, can then be manipulated easily. It could probably be beneficial to add an -angle option (and an accomplanying -angleunit one), to persist a rotation angle in the configuration database. The presence of an angle value other than zero would help negate rotation, thus re-instating the item to its initial orientation. ~ Copyright This document is placed in the public domain.
Log:	This is a supplement to the main log message to allow you to add extra notes if you wish.

Note that when you submit this form, the server will attempt to store your personal details (i.e. name and email address) as cookies in your browser so that next time you edit a TIP, you do not need to retype this info. We do not retain the information on our server (other than as logged in the TIP itself and in the CVS log) and you can delete it without ill-effect if you wish. You are invited to study the implementation code if you wish to understand exactly how the information is stored in your browser.

TIP AutoGenerator - written by Donal K. Fellows