On 28-03-12 08:45, Valerie wrote:
You guys are killing me. D: Hopefully this... 7th iteration or so is the lucky one (at least approach-wise)?
It still needs a lot of work, but the Youtube video and the extra comment on guides were eye-openers, so thanks for that!
Alright, here's the deal: so far the design has either concentrated on dialogue, or on the "base tile", and such. This new design changes the approach (again): this new tiling tool proposal is centered directly on a render frame (with one tile serving as "base" tile).
http://postimage.org/image/vinwmlp6d/ http://postimage.org/image/81v4l35p3/
For me, this is beginning to feel natural. A few pointers:
I think to some degree Josh's comment still applies. There are at least two different toolbars and some dialogs. As a start I think it should be possible to eliminate the edit mode toolbar. Being able to add guide points is something we might want to allow anyway (using the node editor or the snapping toolbar for example). The main thing then would be allowing them to somehow be associated with the object being tiled, but this is also (similar to) something that is needed for connectors for example. Most of the other stuff could probably be moved to the "render mode" toolbar, which would then be more like the tiling tool(bar), having everything that is specific to tiling.
When moving the "tiling type" option to the "render mode"/tiling tool, I'd also allow editing the symmetry handles using that tool. (This part needs some more working
The dynamics options still feel a bit left out, apart from your suggestion of allowing the "regular" dynamics to be edited on-canvas. In fact, I think you could extend that principle to blur and opacity as well. After all, it's possible to edit blur and opacity of clones, and we could relatively easily make sure that changing the blur and/or opacity of a tiled clone would update the other blurs and opacities as well. Even the HSL changes could be done in a similar way, by "interpolating" the feColorMatrix filter primitive for example (although that is probably not entirely equivalent to what it currently does). This currently isn't very accessible from Inkscape's UI, but it probably should be anyway. This would only leave "jitter" and "trace", as well as the "unclump" option, I think. And the unclump option is already present in the align and distribute dialog (so is the jitter option to some extent).
If we are going to link transforms and possibly other attributes of tiled clones in the way discussed above (and like you seem to suggest at least for transforms), it might be good to have an option to "untile" the tiled clones. In the sense that they remain clones, but are no longer considered a tiling.
Finally, It might be good to make an overview of the stages in which your design could be implemented and think about what things could be done more or less independently. This makes it easier to attack the problem bit by bit, also allowing the design to evolve alongside the implementation.
Now as you can see, it should be somehow possible to fit the Dynamics onto the top-level as well. Unfortunately, I'm not as smart as the guy who made that Youtube video, so right now I can't think of a fancy approach to handle it all. The basic idea is that for some dynamics at least, (namely involving position, angle, skew, size and maybe opacity and blur), it should be possible to define them on-canvas through some trick involving the distribution or interpolation of the various frames.
This sounds like a good idea. If I understand correctly your idea is to allow transforming a single tile and then "propagating" that transform to other tiles in such a way that starting from the original/central tile there is a gradual change in the transformation. If so, there are methods to interpolate transforms that would be suitable for something like that, so half a rotation really becomes a rotation by half the angle, etc. (If anyone is interested in the particulars, you essentially compute - fractional - powers of matrices in a particular way.) The main thing is to see whether we'd want to be able to limit the effect of the dynamics in some way (like only after a certain column). Perhaps we could do something a little like node sculpting?
Oh, btw, make sure that "in the end", there is a blueprint or something on your proposal (which can link to the Wiki page for example), as it might take some time to come to an implementation, and it would be a shame if it was "forgotten".