Thanks a lot! Would I be correct to interpret it this way:

1. Basically, the current code would not allow "multiple stops."

2. But it'd still be possible to have a one-stop on-canvas handle

(maybe two, for rows and columns), that basically converts the

end values into percentage values to feed into the current system

3. Since Inkscape doesn't store tiling values right now, changing

the tiling mechanism completely (to allow interpolations) would

not break any backward compatibility or something like that

(not that changing the mechanism is an easy task)

So, the possible way to implement the tiling tool is:

1. First create a separate a "render frame" object (with a central

tile), and make it output values (to feed into the tiling system). It'd

basically be a separate file that can be tested independently.

Also, you can't add or delete tiles individually at this point, just

rows and columns, since the tiling system only handles a "rows

and column" entry at this point.

2. Once it is considered "stable", it is made to call upon the

tiling system, to which it inputs appropriate values.

On-canvas dynamics would require adding to the code for the

render frame object, not the current tiling system. What it'd do is

generate percentage values that are then fed into the tiling

system as well.

So, for a "basic" tiling tool, the tiling system would not need to be

changed much. However, adding both the fuse mode and multi-

node interpolation tiling would requiring significant changes to the

system.

Is that more or less correct?

From: Jasper van de Gronde <th.v.d.gronde@...528...>
To: Valerie <valerie_vk@...36...>
Sent: Wednesday, April 4, 2012 1:24 AM
Subject: Re: [Inkscape-devel] New tiling interface proposal

On 2012-03-31 16:20, Valerie wrote:

Now, I know nothing about programming. Has anyone looked at
the tiling dialogue code yet to see how hard it'd be to mess around

a bit with it? Possibilities to add extra stops etc. even? Replacing

the opacity/blur/color mechanism with a gradient-like approach?

I'm afraid I haven't been able to keep up over the last few days, but I have had a look at the code. For those interested, all the code is in src/ui/dialog/clonetiler.cpp. The main function is CloneTiler::clonetiler_get_transform. This function essentially gets all info, as well as a row and column index. It then computes all the transforms required for that position and combines them. As far as I can tell it combines them in such a way that first a scaling is applied, then a rotation and finally a translation. If you select a different symmetry group then the translation can become a more complicated transform.

The scheme we talked about earlier that would interpolate transforms is not necessarily compatible. This is because in the latter the case the entire transform would be interpolated, while what Inkscape does is essentially interpolating per kind of transform. That this is not the same can be seen by realizing that rotate(50)translate(1)rotate(50)translate(1) is not the same as rotate(100)translate(2). The former is more or less what we talked about (or at least what I had in mind during that discussion), the latter is what Inkscape does.

However, Inkscape currently seems to store almost nothing about the tiling in the file. So it would be relatively benign to change behaviour. Existing files would not be affected in any way, users would only be affected when trying to change a tiling or create a new one. (This is not to say that it's necessarily a good idea to make it impossible to achieve the current behaviour, just that if we cannot reconcile the two, there is some room for change.)

Note that it would be possible to emulate Inkscape's current behaviour through interpolation of transforms, but only if we would allow "stacking" transforms. I'm not sure how this would have to be supported UI-wise though.