When I review the list of bugs in my generic shape editing source, many of them are related to either the behaviour or the final rendering effects of being able to rotate shapes. Rotating shapes in an editing environment, especially those with text, involves a lot more work than people may at first consider:
- Rendering the rotated shape, which may require an additional level of masking on Windows and Linux.
- Drawing drag-shapes as rotated or at least rotated rectangles.
- Drawing the selection outline and handles at rotated positions.
- Changing the cursor type as you mouse-over rotated handles, once you have rotated past 90 degrees.
- Changing the behaviour of constrained resize handles, depending on the angle, as X movement may now for example imply changing the height of the shape rather than width.
- Changing the behaviour of constrained resize or drag, if modifier keys held down, similarly based on shape angle.
- The dilemma of whether to implement rotated inline editing or to jump to a straight edit box (which maps to the issue of using edit boxes for inline editing or rolling your own behaviours).
- Possibly changing or enhancing the behaviour of nudging shape positions with the arrow keys or menu option (I always like to include a menu equivalent). If a shape is rotated, do the arrow keys move it along the XY axes relative to the canvas on which it is drawn or relative to the shape itself or do you give the user the ability to choose as a preference or runtime toggle?
When I consider the domains in which the generic editor is going to be used for our initial products: report-writer layout, screen layout and possible diagram editor, rotation becomes a lot less desirable than the original arbitrary editor required. However, dropping rotation from the common editor does constrain all of those products for now.
Decision: retain rotation code where possible, to avoid too much culling, but remove the UI for the feature so any related bugs can be deferred until the next version.