NEW: optional rounded caps on "calligraphic" strokes
I've just added the ability to round the caps of calligraphic strokes, which is useful when the calligraphic tool is being used with low "fixity" to simulate a round pen (as I often do when inking comics).
Right now there's no UI for it, but the "cap_rounding" parameter for the calligraphic tool can be set to a constant from 0.0 (existing behavior, a flat line) to 1.0 (an approximate half-circle) in preferences.xml.
-mental
MenTaLguY wrote:
I've just added the ability to round the caps of calligraphic strokes, which is useful when the calligraphic tool is being used with low "fixity" to simulate a round pen (as I often do when inking comics).
Right now there's no UI for it, but the "cap_rounding" parameter for the calligraphic tool can be set to a constant from 0.0 (existing behavior, a flat line) to 1.0 (an approximate half-circle) in preferences.xml.
Ka-POW! And then there was UI. This was a long standing desire of mine, thanks!
-Josh
On 9/4/06, MenTaLguY <mental@...3...> wrote:
I've just added the ability to round the caps of calligraphic strokes, which is useful when the calligraphic tool is being used with low "fixity" to simulate a round pen (as I often do when inking comics).
Thanks! A very nice addition. I've just moved the spinbutton to the Angle/Fixation (not fixity :) group, where it makes a little more sense.
I also propose to rename the "Drag" spinbutton into "Wiggle", with a reversal of values (i.e. drag:0 == wiggle:1 and vice versa). I think this would be much more descriptive. Thoughts?
On Wed, 2006-09-06 at 00:05 -0300, bulia byak wrote:
I also propose to rename the "Drag" spinbutton into "Wiggle", with a reversal of values (i.e. drag:0 == wiggle:1 and vice versa). I think this would be much more descriptive. Thoughts?
Hmm, I don't know. "Wiggle" suggests active movement, like "tremor".
If I were to pick an alternate/more descriptive name for "drag" it would probably be "friction" or "damping".
Incidentally, what are we going to do about the width of the toolbar? At this point, the minimum window size almost completely fills my laptop display. That's just too much.
One option might be to make the vertical size of the secondary toolbar variable between tools, and add a second row for tools that needed it, but if we were to do that, we'd need to make sure to scroll the viewport to compensate, so that the actual drawing didn't shift around.
Thoughts?
-mental
On 9/6/06, MenTaLguY <mental@...3...> wrote:
On Wed, 2006-09-06 at 00:05 -0300, bulia byak wrote:
I also propose to rename the "Drag" spinbutton into "Wiggle", with a reversal of values (i.e. drag:0 == wiggle:1 and vice versa). I think this would be much more descriptive. Thoughts?
Hmm, I don't know. "Wiggle" suggests active movement, like "tremor".
And that's exactly what it does when you lower the drag (try it).
If I were to pick an alternate/more descriptive name for "drag" it would probably be "friction" or "damping".
My goal is not to find a synonym, but to give a better idea of what to expect when you change the value away from the default drag=1.
Incidentally, what are we going to do about the width of the toolbar? At this point, the minimum window size almost completely fills my laptop display. That's just too much.
In a word, we need better controls. Text labels are awkward and spinbuttons are very inconvenient. Small sliders with graphic icons would be much much better. Besides the sliders would be stackable in stacks of two (without increasing toolbar height), which would solve the toolbar width problem.
Similarly, I'd love to steal the small edit controls from Xara toolbars, where they are also stacked in twos. Too bad our widget libraries are not compatible...
One option might be to make the vertical size of the secondary toolbar variable between tools, and add a second row for tools that needed it, but if we were to do that, we'd need to make sure to scroll the viewport to compensate, so that the actual drawing didn't shift around.
If we eventually decide to go with that, I'd rather delay this change as much as possible, until such a time when _most_ of the tools need two rows, in which case the switch would be much less of a hassle.
On Wed, 2006-09-06 at 00:27 -0300, bulia byak wrote:
Hmm, I don't know. "Wiggle" suggests active movement, like "tremor".
And that's exactly what it does when you lower the drag (try it).
Whoa, that's bizzare (and not at all what I had assumed, given the tooltip description). Do you find it useful yourself? I'm not sure what I would want it for...
In a word, we need better controls. Text labels are awkward and spinbuttons are very inconvenient. Small sliders with graphic icons would be much much better. Besides the sliders would be stackable in stacks of two (without increasing toolbar height), which would solve the toolbar width problem.
Hmm. Maybe we could switch the text labels to icons to start with?
-mental
On 9/6/06, MenTaLguY <mental@...3...> wrote:
On Wed, 2006-09-06 at 00:27 -0300, bulia byak wrote:
Hmm, I don't know. "Wiggle" suggests active movement, like "tremor".
And that's exactly what it does when you lower the drag (try it).
Whoa, that's bizzare (and not at all what I had assumed, given the tooltip description). Do you find it useful yourself? I'm not sure what I would want it for...
Not really very useful, but setting it at 0.2 and drawing a circle gives me a nice wiggly bubble which would not be too easy to do by hand. So it may have its uses.
Hmm. Maybe we could switch the text labels to icons to start with?
Yes, if someone can volunteer to draw them, now it's a good time to switch to icons :)
As for sliders, I would be happy to stay with spinbuttons, if only GTK would add the nice touch that I've seen in some Windows programs where you can grab the separator between the up and down arrow buttons and drag it vertically, effectively using it as a slider. Very convenient.
On Wed, 2006-09-06 at 03:37 -0300, bulia byak wrote:
Whoa, that's bizzare (and not at all what I had assumed, given the tooltip description). Do you find it useful yourself? I'm not sure what I would want it for...
Not really very useful, but setting it at 0.2 and drawing a circle gives me a nice wiggly bubble which would not be too easy to do by hand. So it may have its uses.
Hmm. Can we try moving it to the tool preferences? I'm not convinced it's worth the space it's taking up on the toolbar.
-mental
On 9/6/06, MenTaLguY <mental@...3...> wrote:
Hmm. Can we try moving it to the tool preferences? I'm not convinced it's worth the space it's taking up on the toolbar.
In that case it's better to remove it at all. If this thing makes sense at all, it's only for turning it on temporarily (by the way, curly hair/fur is another thing you can get with it more easily than without). Moving it to prefs makes this on/off switching nonsensically clumsy.
I, however, am of the opinion that we really can live with it on the main toolbar (after renaming it to Wiggle). It makes perfect logical sense next to Tremor. And if we switch to icon labels, we're not that badly pressed for space... yet :)
I think the switch to standard GKT+ toolbars and actions might help make things easier to rearrange in that dynamic toolbars will be easier to implement.
Would the standard behavior of extra items being moved to a pop-up menu help in this case? Or would getting multiple rows be a better experience?
On Sep 5, 2006, at 8:19 PM, MenTaLguY wrote:
Incidentally, what are we going to do about the width of the toolbar? At this point, the minimum window size almost completely fills my laptop display. That's just too much.
One option might be to make the vertical size of the secondary toolbar variable between tools, and add a second row for tools that needed it, but if we were to do that, we'd need to make sure to scroll the viewport to compensate, so that the actual drawing didn't shift around.
Thoughts?
On Tue, 2006-09-05 at 20:31 -0700, Jon A. Cruz wrote:
Would the standard behavior of extra items being moved to a pop-up menu help in this case? Or would getting multiple rows be a better experience?
I think having multiple rows would work better for widgets that need to be interacted with on a continuous basis (e.g. spinbuttons, as opposed to action buttons).
-mental
participants (4)
-
bulia byak -
Jon A. Cruz -
Joshua A. Andler -
MenTaLguY