Prohibit ambiguity in inkex.Transform constructor arguments

Problem

Right now inkex.Transform(...) accepts keyword argument to construct the transformation.

The order of applied transformations is hardcoded (https://gitlab.com/inkscape/extensions/blob/master/inkex/transforms.py#L240) and has nothing to do with order of keywords.

Such behavior can be considered as part of inkex.Transform public API, but I find it really confusing. It might result to hard-to-find bugs in user code, because code looks perfectly fine (especially when everybody has in mind that recent python versions respect keyword arguments order)

Next two transformations counter-intuitively result to same transformation (translation first, rotation second).

t1 = inkex.Transform(rotate=20, translate=(1,2))
t2 = inkex.Transform(translate=(1,2), rotate=20)

Solution

More clear user code would look like

t1 = inkex.Transform(rotate=20).add_translate(1,2)
t2 = inkex.Transform(translate=(1,2)).add_rotate(20)

To enforce users to write latter and not former without (major) API change I suggest to prohibit non-commuting transformation keywords and raise and error.

E.g.:

inkex.Transform(scale=2,rotate=20) # ok
inkex.Transform(scale=2,transform=(5,10)) # ok
inkex.Transform(scale=(2,3),transform=(5,10)) # ok

inkex.Transform(scale=(2,1),rotate=20) # raises
inkex.Transform(scale=(2,2),rotate=0) # raises 

The latter example actually identity transformation, but I suggest to treat is as potentially ambiguous and raise. If numbers are constants then it should be converted to commuting form (remove null rotation, make scale uniform). If numbers are variable, then it's a potential bug and should be rewritten.

It's still be breaking change though.

Note: scalex, scaley, translatex, translatey are missing

I had this thoughts at first sight on updated Transform API, but I managed to write this issue description just now.