Re: [Inkscape-devel] New tiling interface proposal
For me, this is beginning to feel natural.
Sounds like a start, at least!
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.
True, now that I look at it, my current toolbar is empty enough to combine the two. Previously I had separate toolbars because each guide type had guide-specific options (like arc guides for radial tiling, and numerical fields). And yes, I should add an unclump.
As things stand I think I'll just leave all the numericals inputs to the Transform and Edit Paths tools. And snapping. Users can just snap to something if they need.
Instead, here's how I propose the tiling tool to work. On-canvas, by default you will have a render frame with a base tile: - When using the tiling mode, you can click on the center tile to make handles appear, and from there, modify the handles (who become invisible when not using the tiling tool). - Clicking and dragging the corners of the frame with the tiling tool will add frames to it. You can also shift-drag so new tiles will be created on edges you drag over, or ctrl-shift-drag to delete. - You cannot resize, rotate or move the center tile or the render frame with the tiling tool, but you Can do so with the Transform tool. You can't do those operations from the circle or spiral tools either, so interface-wise the users should be able to get used to it. - As with circles and spirals, double-clicking a center tile or render frame opens up the tiling tool anyway.
I was also thinking of imposing some limitations:
1. No skewing for the center tile, even though P1 and P2 allows for those. The reason is that this would allow users to more easily switch to other symmetries with rectangular tiles. Even if the user's tile design is a skewed rectangle, it's not like they need the base tile to be one anyway.
2. I'm thinking of eliminating the rotation centers and force the users to directly choose say... a P3 guide if that's what he wants. Some handle options may still be available outside of the rectangle guides, but the general shape cannot be changed. The reasoning is: just how desperately does one need to change from P1 to P3 anyway? It may be fun to experiment but it will get confusing fast, and designs for very differently shaped tiles will probably be different too.
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.
I had typed a long list of questions regarding interpolation with some cluttered thoughts regarding the interface, then I saw Veronika's suggestion:
I wonder if the dynamics could be considered as something separate from cloned tiles and could be applied to any selection of objects.
Somehow I think this is simpler too. :S Any objections to treating the features separately?
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 ashame if it was "forgotten".
No problem. I always did intend to make one. But I wanted to make sure that I got to a point where people browsing the blueprints section wouldn't be wondering why said blueprint is redone from scratch every few weeks (as in, at the very least, the general concept should be stable).
And yes, I'm thinking of implementation order too. The pity about the current design is that it isn't as modular as my previous one, but oh well.
Tenacity is worth ten times more than smarts, we can get to the best practical design through discussion and the great critiques.
It also feels like it's taking ten times longer, and I'm starting to miss my other hobbies, but thanks for the encouragement. x)
Not really tiling but not so far. Have a look at that : http://www.youtube.com/watch?v=APGguBZOl10
pygmee
----- Mail original ----- De: "Valerie" <valerie_vk@...36...> À: inkscape-devel@lists.sourceforge.net Envoyé: Mercredi 28 Mars 2012 17:16:02 Objet: Re: [Inkscape-devel] New tiling interface proposal
For me, this is beginning to feel natural.
Sounds like a start, at least!
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.
True, now that I look at it, my current toolbar is empty enough to combine the two. Previously I had separate toolbars because each guide type had guide-specific options (like arc guides for radial tiling, and numerical fields). And yes, I should add an unclump.
As things stand I think I'll just leave all the numericals inputs to the Transform and Edit Paths tools. And snapping. Users can just snap to something if they need.
Instead, here's how I propose the tiling tool to work. On-canvas, by default you will have a render frame with a base tile : - When using the tiling mode, you can click on the center tile to make handles appear, and from there, modify the handles (who become invisible when not using the tiling tool). - Clicking and dragging the corners of the frame with the tiling tool will add frames to it. You can also shift-drag so new tiles will be created on edges you drag over, or ctrl-shift-drag to delete. - You cannot resize, rotate or move the center tile or the render frame with the tiling tool, but you Can do so with the Transform tool. You can't do those operations from the circle or spiral tools either, so interface-wise the users should be able to get used to it. - As with circles and spirals, double-clicking a center tile or render frame opens up the tiling tool anyway.
I was also thinking of imposing some limitations:
1. No skewing for the center tile, even though P1 and P2 allows for those. The reason is that this would allow users to more easily switch to other symmetries with rectangular tiles. Even if the user's tile design is a skewed rectangle, it's not like they need the base tile to be one anyway.
2. I'm thinking of eliminating the rotation centers and force the users to directly choose say... a P3 guide if that's what he wants. Some handle options may still be available outside of the rectangle guides, but the general shape cannot be changed. The reasoning is: just how desperately does one need to change from P1 to P3 anyway? It may be fun to experiment but it will get confusing fast, and designs for very differently shaped tiles will probably be different too.
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.
I had typed a long list of questions regarding interpolation with some cluttered thoughts regarding the interface, then I saw Veronika's suggestion:
I wonder if the dynamics could be considered as something separate from cloned tiles and could be applied to any selection of objects.
Somehow I think this is simpler too. :S Any objections to treating the features separately?
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 ashame if it was "forgotten".
No problem. I always did intend to make one. But I wanted to make sure that I got to a point where people browsing the blueprints section wouldn't be wondering why said blueprint is redone from scratch every few weeks (as in, at the very least, the general concept should be stable).
And yes, I'm thinking of implementation order too. The pity about the current design is that it isn't as modular as my previous one, but oh well.
Tenacity is worth ten times more than smarts, we can get to the best practical design through discussion and the great critiques.
It also feels like it's taking ten times longer, and I'm starting to miss my other hobbies, but thanks for the encouragement. x) ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 28-03-12 17:16, Valerie wrote:
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.
True, now that I look at it, my current toolbar is empty enough to combine the two. Previously I had separate toolbars because each guide type had guide-specific options (like arc guides for radial tiling, and numerical fields). And yes, I should add an unclump.
The unclump option is already in the align and distribute dialog.
... I was also thinking of imposing some limitations:
- No skewing for the center tile, even though P1 and P2 allows for
those. The reason is that this would allow users to more easily switch to other symmetries with rectangular tiles. Even if the user's tile design is a skewed rectangle, it's not like they need the base tile to be one anyway.
This might give some problems when used with the fuse cut method (with or without borders). In principle the user can obviously create a design based on a rectangular tile, but this might not be the most natural. On the other hand, going the other way and allowing interactive editing of the tile might also not be the best way to go, so perhaps you're right, but still.
- I'm thinking of eliminating the rotation centers and force the users
to directly choose say... a P3 guide if that's what he wants. Some handle options may still be available outside of the rectangle guides, but the general shape cannot be changed. The reasoning is: just how desperately does one need to change from P1 to P3 anyway? It may be fun to experiment but it will get confusing fast, and designs for very differently shaped tiles will probably be different too.
This reasoning is partly correct, and I agree that this would definitely not be a "must". On the other hand, I think that some changes might be quite logical, so at some point it might be nice to have the option.
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.
I had typed a long list of questions regarding interpolation with some cluttered thoughts regarding the interface, then I saw Veronika's suggestion:
I wonder if the dynamics could be considered as something separate from cloned tiles and could be applied to any selection of objects.
Somehow I think this is simpler too. :S Any objections to treating the features separately?
Partially. One of the things that would make interpolation work really well with tiled clones is that they are conceptually laid out in a grid, so it is clearly defined how many "steps" there are between two objects (even for hexagonal/triangular grids this is not too difficult). With an arbitrary selection of objects this is less so. Of course x/y positions could be used, but I'm not sure this is necessarily what you want. As for the Youtube video, I think I missed that one.
Also, for blur it is quite essential that discrete objects have a single blur value, as SVG does not support "spatially-varying" blur (and it is non-trivial to do support it).
Of course this does not hold for tracing. And jitter and unclump already are available from the align and distribute dialog (to a certain degree at least). But for the more regular transforms and such I'm just not 100% sure that it would suffice.
Still on the topic of having the dynamic properties separate from the tiling tool:
Jasper:
One of the things that would make interpolation work really well with tiled clones is that they are conceptually laid out in a grid, so it is clearly defined how many "steps" there are between two objects
I think of the "dynamic options" more as "discrete options" - using the columns and rows you bucket the objects into cells and apply an interpolated value for the whole cell. Using that idea, I think you could apply the discrete options to any selection of objects by superimposing a grid.
Here is a diagram to show what I mean: http://i.imgur.com/eL85r.png
With the grid you can be very flexible, it doesn't have to be Cartesian - you can change the spacing of the grid (in one dimension or both), change the orientation, skew it, rotate it, choose something other than a rectangular grid such as a polar grid or a grid with exponential spacing. One day you could even allow fancy editing of the grid to create custom distortions.
An object is assigned the value corresponding to the cell it overlaps with most. If the object completely covers multiple cells, it is assigned a value based on the average of the underlying cells (I think the current cloned tile tracing behaviour does something like this and could be used as the model).
Jasper:
Also, for blur it is quite essential that discrete objects have a single blur value, as SVG does not support "spatially-varying" blur (and it is non-trivial to do support it).
And in a later post:
Jasper:
I've been thinking about this, and I think the most natural method would probably be to act more or less like a gradient does, so the start tile would be the first stop, and the reference tile the last.
You have stated it better than I did. This is what I meant by it would be great if blur could be applied in a way similar to gradient. Yes it is discrete but it would be nice to set a start and stop value and let the blur values in between be interpolated and applied in a step wise fashion. In my diagram the line with the circle and square end points is meant to represent the start and stop value like the gradient tool. Allowing multiple changes (like the gradient tool) would be awesome too.
I think these discrete options could appear mixed in with the existing alignment, fill etc dialogs. Or the could be turned into a dialog of their own but to me that would make them harder to discover.
Veronika
(I've subtly changed the title to reflect that this is specifically about dynamics.)
On 29-03-12 18:20, Veronika wrote:
Still on the topic of having the dynamic properties separate from the tiling tool:
Jasper:
One of the things that would make interpolation work really well with tiled clones is that they are conceptually laid out in a grid, so it is clearly defined how many "steps" there are between two objects
I think of the "dynamic options" more as "discrete options" - using the columns and rows you bucket the objects into cells and apply an interpolated value for the whole cell. Using that idea, I think you could apply the discrete options to any selection of objects by superimposing a grid.
Here is a diagram to show what I mean: http://i.imgur.com/eL85r.png
With the grid you can be very flexible, it doesn't have to be Cartesian - you can change the spacing of the grid (in one dimension or both), change the orientation, skew it, rotate it, choose something other than a rectangular grid such as a polar grid or a grid with exponential spacing. One day you could even allow fancy editing of the grid to create custom distortions. ...
I think the idea of separating dynamics from tiled clones is very interesting, but it does sound like it might become a bit complicated. Essentially with tiling you already have a well-defined structure that you can leverage. More or less forgetting about that structure and devising some other way to apply structure (a grid) to the objects seems like a convoluted way of doing things. If it turns out in practice that it is more useful or just as useful to base dynamics on a continuous field that is simply "sampled" by the tiled clones (similar to how tracing works), then I guess that would definitely be a valid option. Also because that corresponds really well to how gradients already work. But I'm not convinced (yet) that adding another way to somehow define a grid over objects to apply dynamics would make sense.
But feel free to try and convince me (and others) :)
How about this for a possible dynamics interface: http://www.tomlechner.com/randompics/finishing.png
If you start with a blank strip only those settings you change are applied. If one node has a setting changed, and another doesn't, then interpolate with the object's original setting. Perhaps hover or double click over nodes to pop up an info box with what settings are changing, perhaps also allowing to toggle whether that node affects those settings (or have toolbar for that if you insist).
If you want to use different grid systems, they could be variations on the bilinear option, but editing those would be a task in itself! Perhaps in the short term, just have an option to apply different grids available to only scripting?
It's common to want to randomize within specific bounds, maybe instead of dragging the marks themselves, clicking on a randomize mark could toggle visibility of a randomize boundary.
A downside of this is that it stuffs a ton of possibly unrelated styles into the same nodes. Many times this would be ok, but one might want to stack strips instead.
-Tom
I think the idea of separating dynamics from tiled clones is very interesting, but it does sound like it might become a bit complicated. Essentially with tiling you already have a well-defined structure that you can leverage.
I have been playing with the grid idea and I think it was the wrong approach. A much simpler way is to just use the (x,y) coordinates of the point at the center (center of balance) of the object. I haven't looked at the code but I think this may be what the Trace tab in the Clone Tile dialog does.
There is a difference between using the (x,y) spatial position versus the (row, column) position. In the following image I have explored this a bit:
Apart from the "randomized shift", the difference between the two approaches is very subtle. For example, the (x,y) approach gives more fully saturated squares than the (row, column) approach in the Changing Size and Changing Shift columns. However, I would argue that the user could tweak the gradient to get the desired effect with the (x,y) position.
The exception may be someone building a data visualization in which exact values (rather than depending on the interpolated values) are important. Since this is a fringe case, and one in which it might be better to generate the SVG using a script, I think the general use case should be given preference.
Regarding the randomized shift effect (see first column in diagram), I think that any property should have a randomized value selector. This way, I can select a number of objects then open the dialog for the property and select "random" - nice to be able to give a range for the values - and have the properties set accordingly. I think this is a more direct way to get the desired effect than randomly shifting the tiles.
I think the gradient approach makes for a very interface. A gray scale image of a colour gradient could be used to visualize the effect. As the gradient tool evolves, so can the ability in the other properties. For example, one day the user may be able to define the type of interpolation use in the gradient tool - not just linear. (BTW - the Maya tool has a very nice UI for manipulating the interpolation function, for reference). This can be directly applied to the other properties.
And finally, if a gradient isn't rich enough, the user can always provide an image. The algorithm would work in the same way - just using the values in the image.
Cheers, Veronika
On 2012-03-30 22:12, Veronika wrote:
I think the idea of separating dynamics from tiled clones is very interesting, but it does sound like it might become a bit complicated. Essentially with tiling you already have a well-defined structure that you can leverage.
I have been playing with the grid idea and I think it was the wrong approach. A much simpler way is to just use the (x,y) coordinates of the point at the center (center of balance) of the object. I haven't looked at the code but I think this may be what the Trace tab in the Clone Tile dialog does.
There is a difference between using the (x,y) spatial position versus the (row, column) position. In the following image I have explored this a bit:
Nice to see that you explored this a bit. I think that this would indeed be the main contender for a separate dynamics tool. I'm still a little worried about simply breaking completely with the existing functionality though.
My recommendation to mitigate concern is as follows:
1) Liberate the Trace tab from Cloned Tiles. The behaviour is based on x,y position, not row,column and can therefore be applied to any selection of objects. The functionality should probably be part of the Fill and Stroke dialog.
2) Add support for Blur to "Tracing" - support for Opacity exists so I don't think there is any reason Blur can not be supported in a similar fashion.
3) In addition to using an image, add support for a gradient (same as creating an image with a gradient, but automate the step of creating the image for the user - also remove the need to show/hide the image in this basic case). If it can be made fast enough, show a live preview of the change to the property as the gradient is being modified (e.g. show change in blur as end points for line of gradient are moved around). Note: Gamma correction and inversion would only apply if an image is used and would not be applicable for a gradient.
4) Extend support in gradient to non-linear interpolations. Currently gradients are linear - amount of change at each "step" is the same everywhere between the two endpoints, like a constant velocity. In contrast, the changes could begin slowly and an increase towards the end, like constant acceleration (or inversely, start fast and decrease, like deceleration), or the acceleration could be variable and follow a curve such as a sine curve or exponential curve.
5) For the options (hue, saturation, lightness, blur, opacity, ) evaluate whether these "Tracing" controls are sufficient to replace the (row,column) approach. If the functionality is deemed equivalent, simplify the Cloned Tiles tool by removing the functionality.
4) and 5) can probably be done in any order.
Veronika
On Sat, Mar 31, 2012 at 11:47 AM, Veronika <vmi@...2827...> wrote:
My recommendation to mitigate concern is as follows:
- Liberate the Trace tab from Cloned Tiles. The behaviour is based on x,y
position, not row,column and can therefore be applied to any selection of objects. The functionality should probably be part of the Fill and Stroke dialog.
Can you explain how you think it would be appropriate for the Fill & Stroke dialog? I can't come up with any way that it makes sense.
- Extend support in gradient to non-linear interpolations. Currently
gradients are linear - amount of change at each "step" is the same everywhere between the two endpoints, like a constant velocity. In contrast, the changes could begin slowly and an increase towards the end, like constant acceleration (or inversely, start fast and decrease, like deceleration), or the acceleration could be variable and follow a curve such as a sine curve or exponential curve.
Would such a change be compatible with the SVG specification? I'm legitimately asking because I haven't read that part in years (and don't have the time to right now). One thing you need to be wary of is making arbitrary changes in Inkscape that aren't supported by the SVG spec. We have plenty of features that aren't in the SVG spec, however, we need to have proper fallbacks to ensure we are doing things in a compatible way for other renderers.
Cheers, Josh
On Sat, 2012-03-31 at 13:18 -0700, Josh Andler wrote:
On Sat, Mar 31, 2012 at 11:47 AM, Veronika <vmi@...2827...> wrote:
- Extend support in gradient to non-linear interpolations. Currently
gradients are linear - amount of change at each "step" is the same everywhere between the two endpoints, like a constant velocity. In contrast, the changes could begin slowly and an increase towards the end, like constant acceleration (or inversely, start fast and decrease, like deceleration), or the acceleration could be variable and follow a curve such as a sine curve or exponential curve.
Would such a change be compatible with the SVG specification? I'm legitimately asking because I haven't read that part in years (and don't have the time to right now). One thing you need to be wary of is making arbitrary changes in Inkscape that aren't supported by the SVG spec. We have plenty of features that aren't in the SVG spec, however, we need to have proper fallbacks to ensure we are doing things in a compatible way for other renderers.
Only linear gradient interpolations are defined in the specification at the moment. I know Chris Lilley has talked about expanding the ways interpolations can be defined but I don't see that in the list of SVG2 requirements.[1] Clearly Inkscape can simulate more complex interpolations by adding more stops.
Tav
[1]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
1) Liberate the Trace tab from Cloned Tiles.
From Josh: Can you explain how you think it would be appropriate for the Fill & Stroke dialog? I can't come up with any way that it makes sense.
At first I was thinking that the functionality would be similar to what is currently done with the Tiled Clones dialog. That is, the action would be a one time thing and the data would not be preserved (similar to how alignment is done in the Align and Distribute dialog). In this sense, it seemed logical to have it in the Fill and Stroke dialog beside each of the relevant properties (a button for example at the end of the property, similar to the button that appears in the "Remove Overlaps" section of the the Align and Distribute dialog). However, an additional step is required to create the gradient so the button would have to launch you into a gradient editing mode which is a bit weird. Also, after the user has put the effort in to defining a gradient, it is a shame to lose it.
So thinking a bit more about it, maybe the functionality belongs in the gradient tool. Here is an image showing how the gradient toolbar could change to support discrete gradients and possibly image tracing:
The discrete gradient seems to fit well here. I am not quite as comfortable with the image tracing. Would users be surprised to find it under the gradient tool? There are quite a few choices to make and this may be a bit too much to put in the toolbar. However, the image tracing is doing the same thing as the discrete gradient functionality - in the discrete gradient case the image just happens to be a gradient. So in that sense it does belong here and is a logical next step if the user can not get the result they desire from a gradient.
4) Extend support in gradient to non-linear interpolations.
From Josh: Would such a change be compatible with the SVG specification?
Good point. I don't want to introduce crazy hacks.
From Tav: Clearly Inkscape can simulate more complex interpolations by adding more stops.
Thank you for checking into the specification and great suggestion. Adding more stops is how the user would achieve this affect today but the process is tedious and to get it right they may have to go off and make some calculations. The nature of these calculations is probably beyond some users. It would be nice to have this done automatically. The number of intermediate stops would need to be limited to a reasonable number for performance (and could maybe be chosen by the user).
I forgot to add one more point to my original proposal:
7) Liberate the Randomize button from Cloned Tiles. Like tracing, it does not depend on row and column position. It already exists for the alignment option but it would be nice to see this on other options. Since this really is a one time thing, I think it belongs in the Fill & Stroke dialog. See the image below:
In the image above there is a button beside each of the properties (h, s, l, alpha, blur, opacity). Select a bunch of objects and click on the button. A dialog will prompt the user for the start and end values of the range and then apply a different random value to that property each of the selected objects.
Cheers, Veronika
-----Original Message----- From: Josh Andler Sent: Saturday, March 31, 2012 1:18 PM To: Veronika Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] New dynamics interface proposal
On Sat, Mar 31, 2012 at 11:47 AM, Veronika <vmi@...2827...> wrote:
My recommendation to mitigate concern is as follows:
- Liberate the Trace tab from Cloned Tiles. The behaviour is based on
x,y position, not row,column and can therefore be applied to any selection of objects. The functionality should probably be part of the Fill and Stroke dialog.
Can you explain how you think it would be appropriate for the Fill & Stroke dialog? I can't come up with any way that it makes sense.
- Extend support in gradient to non-linear interpolations. Currently
gradients are linear - amount of change at each "step" is the same everywhere between the two endpoints, like a constant velocity. In contrast, the changes could begin slowly and an increase towards the end, like constant acceleration (or inversely, start fast and decrease, like deceleration), or the acceleration could be variable and follow a curve such as a sine curve or exponential curve.
Would such a change be compatible with the SVG specification? I'm legitimately asking because I haven't read that part in years (and don't have the time to right now). One thing you need to be wary of is making arbitrary changes in Inkscape that aren't supported by the SVG spec. We have plenty of features that aren't in the SVG spec, however, we need to have proper fallbacks to ensure we are doing things in a compatible way for other renderers.
Cheers, Josh
Whoops image was not complete when I uploaded it - missing the "Apply to:" options for Discrete gradient. It should look like this:
-----Original Message----- From: Veronika Sent: Sunday, April 01, 2012 10:23 AM To: Inkscape-devel Subject: Re: [Inkscape-devel] New dynamics interface proposal
1) Liberate the Trace tab from Cloned Tiles.
From Josh: Can you explain how you think it would be appropriate for the Fill & Stroke dialog? I can't come up with any way that it makes sense.
At first I was thinking that the functionality would be similar to what is currently done with the Tiled Clones dialog. That is, the action would be a one time thing and the data would not be preserved (similar to how alignment is done in the Align and Distribute dialog). In this sense, it seemed logical to have it in the Fill and Stroke dialog beside each of the relevant properties (a button for example at the end of the property, similar to the button that appears in the "Remove Overlaps" section of the the Align and Distribute dialog). However, an additional step is required to create the gradient so the button would have to launch you into a gradient editing mode which is a bit weird. Also, after the user has put the effort in to defining a gradient, it is a shame to lose it.
So thinking a bit more about it, maybe the functionality belongs in the gradient tool. Here is an image showing how the gradient toolbar could change to support discrete gradients and possibly image tracing:
The discrete gradient seems to fit well here. I am not quite as comfortable with the image tracing. Would users be surprised to find it under the gradient tool? There are quite a few choices to make and this may be a bit too much to put in the toolbar. However, the image tracing is doing the same thing as the discrete gradient functionality - in the discrete gradient case the image just happens to be a gradient. So in that sense it does belong here and is a logical next step if the user can not get the result they desire from a gradient.
4) Extend support in gradient to non-linear interpolations.
From Josh: Would such a change be compatible with the SVG specification?
Good point. I don't want to introduce crazy hacks.
From Tav: Clearly Inkscape can simulate more complex interpolations by adding more stops.
Thank you for checking into the specification and great suggestion. Adding more stops is how the user would achieve this affect today but the process is tedious and to get it right they may have to go off and make some calculations. The nature of these calculations is probably beyond some users. It would be nice to have this done automatically. The number of intermediate stops would need to be limited to a reasonable number for performance (and could maybe be chosen by the user).
I forgot to add one more point to my original proposal:
7) Liberate the Randomize button from Cloned Tiles. Like tracing, it does not depend on row and column position. It already exists for the alignment option but it would be nice to see this on other options. Since this really is a one time thing, I think it belongs in the Fill & Stroke dialog. See the image below:
In the image above there is a button beside each of the properties (h, s, l, alpha, blur, opacity). Select a bunch of objects and click on the button. A dialog will prompt the user for the start and end values of the range and then apply a different random value to that property each of the selected objects.
Cheers, Veronika
-----Original Message----- From: Josh Andler Sent: Saturday, March 31, 2012 1:18 PM To: Veronika Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] New dynamics interface proposal
On Sat, Mar 31, 2012 at 11:47 AM, Veronika <vmi@...2827...> wrote:
My recommendation to mitigate concern is as follows:
- Liberate the Trace tab from Cloned Tiles. The behaviour is based on
x,y position, not row,column and can therefore be applied to any selection of objects. The functionality should probably be part of the Fill and Stroke dialog.
Can you explain how you think it would be appropriate for the Fill & Stroke dialog? I can't come up with any way that it makes sense.
- Extend support in gradient to non-linear interpolations. Currently
gradients are linear - amount of change at each "step" is the same everywhere between the two endpoints, like a constant velocity. In contrast, the changes could begin slowly and an increase towards the end, like constant acceleration (or inversely, start fast and decrease, like deceleration), or the acceleration could be variable and follow a curve such as a sine curve or exponential curve.
Would such a change be compatible with the SVG specification? I'm legitimately asking because I haven't read that part in years (and don't have the time to right now). One thing you need to be wary of is making arbitrary changes in Inkscape that aren't supported by the SVG spec. We have plenty of features that aren't in the SVG spec, however, we need to have proper fallbacks to ensure we are doing things in a compatible way for other renderers.
Cheers, Josh
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (7)
-
unknown＠example.com -
Jasper van de Gronde -
Josh Andler -
Tavmjong Bah -
Tom Lechner -
Valerie -
Veronika