On 2013-07-11 04:35 +0100, Martin Owens wrote:
I've committed two intemediatary refactors to make the logic easier to move out:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12411 http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12413
It reduces code size by 68 lines as well as reducing the interaction between the action class and the AlignAndDistribute class. I checked up on the two mentioned hacks/bugs I cleared up and testing for them shows no ill effect with the new code.
There is an addition to the Selection class: largestItem(...) and smallestItem(...) which in turn call a private _sizeistItem(...) that allows any function to return the largest/smallest item by width, height or area. I'd have liked to use the width/height/area Geom::OptRect functions but they're missing in this specific class and I couldn't really tell why they were available to some Rects and not others since the code looks the same. (obviously libgeom changes are a no-go)
Testing r12314 / 12415 on OS X 10.7.5:
These changes (r12413/r12414) break (or at least unexpectedly modify) one type of alignment:
Relative to: First selected | Last selected | Biggest object | Smallest object
- Align right sides to left side of anchor - Align left sides to right side of anchor - Align top sides to bottom side of anchor - Align bottom sides to top side of anchor
See also: http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Align.html#Align-Align
Steps to reproduce: 1) launch inkscape (default prefs, new doc based on default template) 2) draw three objects with visibly different sizes 3) select all 4) open 'Align & Distribute', select 'Relative to: Smallest object' 5) align e.g. 'right sides to left side of anchor'
Expected result (as in trunk <= r12412): The object meeting the 'Relative to:' criteria is used as anchor and stays fixed, while the rest of the selection is aligned according to the chosen command.
Actual result (trunk r12414, r12415): All objects are moved, including the one which acts as anchor, and aligned to the position of the respective bbox edge of the original position of the anchor object.
Just curious - is this an intentional change? (A local build of your 'align-handles' branch (r12410) does not expose the same change in behavior.)