On Mon, Mar 17, 2008 at 10:59 AM, Bill Skaggs <[EMAIL PROTECTED]> wrote:
> David G. <[EMAIL PROTECTED]> wrote:
> > I proposed this because it will actually boost the simplicity
> > of managing brushes to adapt in effects and splashes, instead
> > of doing the layer and rotation "technique". ...
> I gather from this that you would like to be able to pick
> an arbitrary rotation, and that simply rotating in the
> direction of motion wouldn't fit your needs.
There are indeed many brushes which would work best with a specific
angle control -- they are mainly 'edge-effect' brushes. Anyway, I've
already stated my belief that if you have directional rotation, a
normative rotation angle control is necessary.
> > Maybe in the eyes of a developer this might be considered 'bloat'.
> It isn't a question of bloat, it's a question of keeping the user
> interface as simple as possible while providing the capabilities
> that are wanted. Adding an option that doesn't get used is
> not harmless: it makes it harder to find the things that are
> important. As an artist, you wouldn't want to have the
I believe that we can reduce the number of
screen-real-estate-occupying options anyway, and
use an interface like the ink tool nib adjuster to simultaneously set
brush normative rotation and aspect ratio.
Also possibly scale -- being able to use the scroll wheel on the nib
adjuster to change brush scale makes sense to me, skew -- ctrl+drag to
skew, flip -- shift-click near a border to flip on that axis, and
aspect -- shift-drag.
(to be congruent with the rest of the GIMP, it would probably be
better to put skew on shift and aspect+flip on control, since shift
typically adds and control typically constrains.)
As far as the backend goes, I would expect values for skew, rotate,
aspect, flip, scale to be independently stored and modifyable by
keyboard shortcut*, and mostly combined** into one transform matrix
after a value changes.
*by which I mean that they can be shortcutted, not that they are by default.
** looking at the brush code, differently scaled versions of the brush
are cached. If directional rotation was implemented, we'd want to
cache rotations as well, I expect. So the transform might work better
in two steps.
An example of this kind of interface in a raster paint program is in
> controls you need buried amongst 20 useless buttons and
> sliders, would you? That's why everything like this needs
> discussion and careful consideration.
> -- Bill
> Gimp-developer mailing list
Gimp-developer mailing list