I also have a certain need for that feature, and i have been investigating. The problem with that feature is that to make it you would need to add some sort of guide to the selection box item to enable people to rotate it. To do this you would have to subclass the gobject of GnomeCanvasRect, and i don't know how the mantainer feels about it since there is no such thing present in the code.
Another solution would be to make a group of items but that would need a great code rewrite.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding aiwarrior's comment: I don't like the idea of digging into the internals of GnomeCanvas -- long-term one might want to become independent of gnomecanvas (as it's not integrated with cairo and may become technically obsolete even though there's no standard anti-aliased canvas to replace it yet), not more dependent on its internals.
That being said: I don't think having guides necessarily requires digging into gnomecanvas internals. One can just have the selection be marked by more than just a GnomeCanvasRect on the screen -- it could be several GnomeCanvas items, e.g. the rectangle + a small thingie that materializes a rotation handle. The event-processing code that looks into what happens when one clicks into the canvas already does the job of deciding whether a button press is the beginning of a selection move, selection resize, or a new drawing/selection. Having a subcase in the decision tree to start a rotation wouldn't be an issue.
Visually: one could imagine that only the selection rectangle rotates while the rotation is taking place, or all the selected items get rotated in realtime (probably using affine transforms on the canvas items), one would have to check performance on low-end machines. In any case, probably no need to recalculate all coordinates in the Item data structures. After the rotation is done, the calculates get recomputed (and probably it'd be safer to repaint the canvas items without affine transformation and with the new coordinates).
(A group would make it very slightly easier to rotate all the items at once but really it doesn't save much, and from what I understand of gnomecanvas' implementation it wouldn't be faster; plus, the cost is that the items would have to be reparented in reset_selection() before the selection group gets destroyed. I think whether to use a GnomeCanvasGroup for the selection items or not is a minor design decision, unlikely to have a significant impact on anything).
Denis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also have a certain need for that feature, and i have been investigating. The problem with that feature is that to make it you would need to add some sort of guide to the selection box item to enable people to rotate it. To do this you would have to subclass the gobject of GnomeCanvasRect, and i don't know how the mantainer feels about it since there is no such thing present in the code.
Another solution would be to make a group of items but that would need a great code rewrite.
Regarding aiwarrior's comment: I don't like the idea of digging into the internals of GnomeCanvas -- long-term one might want to become independent of gnomecanvas (as it's not integrated with cairo and may become technically obsolete even though there's no standard anti-aliased canvas to replace it yet), not more dependent on its internals.
That being said: I don't think having guides necessarily requires digging into gnomecanvas internals. One can just have the selection be marked by more than just a GnomeCanvasRect on the screen -- it could be several GnomeCanvas items, e.g. the rectangle + a small thingie that materializes a rotation handle. The event-processing code that looks into what happens when one clicks into the canvas already does the job of deciding whether a button press is the beginning of a selection move, selection resize, or a new drawing/selection. Having a subcase in the decision tree to start a rotation wouldn't be an issue.
Visually: one could imagine that only the selection rectangle rotates while the rotation is taking place, or all the selected items get rotated in realtime (probably using affine transforms on the canvas items), one would have to check performance on low-end machines. In any case, probably no need to recalculate all coordinates in the Item data structures. After the rotation is done, the calculates get recomputed (and probably it'd be safer to repaint the canvas items without affine transformation and with the new coordinates).
(A group would make it very slightly easier to rotate all the items at once but really it doesn't save much, and from what I understand of gnomecanvas' implementation it wouldn't be faster; plus, the cost is that the items would have to be reparented in reset_selection() before the selection group gets destroyed. I think whether to use a GnomeCanvasGroup for the selection items or not is a minor design decision, unlikely to have a significant impact on anything).
Denis