That's pretty interesting. In fact, this and working on the GUI for tiling have made me think more about on-canvas templates in general. There's quite a bit of potential for just dropping stuff onto the canvas for various outcomes (you can turn them on and off). Possibilities include:
1. Clone/iteration templates: the render frame for the tiling tool is kind of like an on-canvas clone template, right?
The link you provided could be an iteration template. Drop an iteration area, drop an object inside it, then manipulate the whole to activate iteration within the area.
2. Kinematic templates: "improves freehand drawing by altering the cursor's movements."
More info at http://hci.uwaterloo.ca/research/kinematic (really cool stuff).
3. Deform templates
An idea I've had recently: create a perspective grid (for example, over the side of a building), and if you grab and hover any object over it for a few seconds (example: a 2D window design), the object will have an automatic perspective deform applied to it. Moving the object along the grid behaves a bit like what happens with the 3D box tool. Also, when you draw straight lines within the area, they snap to the direction of the grid's vanishing points.
Another deform template could be a mesh grid that you can edit before dropping some object onto it (example: a mesh grid to simulate a wavy flag. You can then drop the 2D design of any country flag onto it)
Although some of it sounds more suited to 3D programs, a user could very well want to make a wavy flag in Inkscape, or some simple box icons with decorations on the side for example.
4. Render templates
Basically things you would currently find under extensions -> Render in Inkscape (L-systems, trees etc.), except once they are on-canvas you can edit them there.
Of course, although the ideas sound cool, programming would be another issue. And all that real-time rendering would totally kill a few CPUs.
On 16-05-12 16:53, Valerie wrote:
... Of course, although the ideas sound cool, programming would be another issue. And all that real-time rendering would totally kill a few CPUs.
Don't let that worry you too much :) First of all, rendering a bunch of shapes isn't necessarily that slow, and secondly, there are usually some tricks to make the speed acceptable when it is. As for the programming complexity, yeah, it would be non-trivial, but since when did that stop anyone? (Frankly, it's more the "sounds stupid, but involves a whole lot of code refactoring" tasks that usually don't get done.)
participants (2)
-
Jasper van de Gronde
-
Valerie