summer of code

Valerie valerie_vk at yahoo.com
Thu Mar 20 15:13:08 CET 2008


> Yes but the type of shape is dependend of the type of algorithm. 
> That's the problem.

Actually, the mockups were supposed to convey just that. I suppose
I didn't do a good enough job. Depending on the brush type/algorithm
you chose, Everything changes (which is why I added that perhaps,
the choice of algorithm should be top-level when making a new
brush, and once you've chosen it, you can never modify it again):

- the available brush shape options. For example, "broom" and other
Chinese ink options only appear for Chinese ink. But you may have
several shape algorithms for Chinese ink, in which case the user
gets to choose. If no such options exist, the only existing form
gets loaded. 

- the "stuff on the left." They take on more painterly options
depending on the brush type. Problem is, I don't know what such
options are, so I didn't make a corresponding mock-up. :P 

- when some of the stuff in "main" can be dynamic, they get moved
entirely to a corresponding and properly-named sub-category.

> Shortcuts and toolbar are best managed by Settings > Shortcuts
> and Settings > toolbar, this is needed to follow KDE's UI guide lines.

Perhaps this is a UI guide lines issue, but from a user POV the
ability to chose what toolbar options appear for each type of
preset is a plus, not a minus. It allows the user to chose what
appears overhead without cluttering the screenspace. It's a mini-
workspace concept basically.

Tool options cluttering the whole area is one of the biggest
weaknesses of Gimp. Also, most programs don't have the tool 
options diversity of Krita, that's the big difference.

Shortcuts can be another matter, as long as the user gets pointed
to the direction of the shortcuts. I can think of an alternative
though: in a general shortcuts setting, a user can chose to have
[, ] and other such keys defined to modify "Tool parameter 1",
"Tool parameter 2" etc. Then the brush panel defines/can be used
to define what said parameters are. Basically, there are more
possible parameters out there than available intuitive shortcuts:
size, opacity, wetness, grain, length of size/color/whatever fade,
length of bristles, density of bristles, etc, so unless they get 
chosen on a preset by preset basis (or at best, algorithm by
algorithm basis), then the whole concept is wasted so to say.

Besides, I admit that I do like Gnome's option of modifying
behavior where it's at: ie click the toolbar and get toolbar
options. I don't see the problem interface-wise with that. 
There's room for both. But hey. Would the compromise work?

> But what would be hell is to refactor all this to appear in similar 
> dialog.

And if they do appear in a similar dialog, said dialog would be
so huge that users would complain, as if the Gimp dialogs don't
take up enough space as well. :P

Which is why I thought of a way for users to stuff what they think
is important in the toolbar, once and once and for all, then never
have to load the bulkier dialogs. :)

Ever seen videos of how Photoshop users go about? When they have to
modify something, they load up the entire big panel using a
shortcut, then close it as soon as the modification gets done. But
back when I tried Painter Classic, I remembered there being a few
sliders at the bottom: opacity, grain, maybe one other thing and
that's about it. That didn't take up much space though, and it was
really handy to have around.


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs


More information about the kimageshop mailing list