Sorry for sending you this twice, Michael. Missed the "reply all"
button the first time through.

One thing I do want to add to what's below is, just to clear it up:
I'm not pressing for a generic "solution" that allows anybody to
implement any custom tools in the tool palette that they may want. My
view is that primitive drawing is not a special-purpose, uncommon
tool, but rather it is an integral feature of any image editing
application, and it is a feature that gimp is specifically lacking.

That said:

On Tue, Apr 29, 2008 at 6:10 PM, Michael J. Hammel
<[EMAIL PROTECTED]> wrote:
> On Tue, 2008-04-29 at 17:11 -0400, Jason Cipriani wrote:
>  > An alternative approach to having a new tool is to just add something
>  > to the menu like "draw border around selection", which just automates
>  > the current select + fill + shrink + (cut or fill) process.
>
>  Adding a menu item is just a matter of scripting the function in one of
>  the supported languages or writing a C plugin.

Oh, that's cool.

>  > to show
>  > whatever dialog is associated with this, and a keystroke to repeat the
>  > last settings, would cover just about everything and wouldn't require
>  > any major UI changes -- it just uses the existing selection
>  > functionality and automates a really common task.
>
>  My problem with this is that while drawing borders may be a very common
>  task for you, there are many users for which it is never (or nearly
>  never) used. So adding a button for this task to the Toolbox falls into
>  my definition of feature creep.

I disagree based on three points:

1) There is a reason that "how do I draw a box" is in the FAQ,
emphasis on the F.

2) Photoshop can draw boxes (they keep it clean by combining all the
primitive drawing tools into a single palette button, but Photoshop
has the advantage of having those palette buttons that expand when you
hold the left button down on them, I don't know if gimp has that).

3) I strongly believe that all image editing programs should have a
superset of the UI functionality of mspaint.

>  If you don't make such decisions, you end up with far more UI
>  components than the average person actually needs.  I believe MS Word
>  was the major culprit of this effect at one time though it's been years
>  since I've used Word so maybe they've fixed that.

Programs like Word have a lot of feature creep, but allowing you to
customize the buttons that appear on the toolbar and the commands that
appear in the menu is a good way to let you keep the interface clean.

>  Looking at Evolution's editor as I type this I can spot 11 icons (out of
>  14) in the toolbar that I never use.  Never.  Still, I use their
>  functionality by utilizing keyboard accelerators and menus.  So should
>  there be icons?  Not for me - they're meaningless.  It's pretty much
>  wasted space.  Does that make them useless?  Not to everyone.

Just as drawing primitives is not useless to everyone. Still, the
problem there is Evolution's lack of a customizable tool bar. Once the
UI becomes cluttered in that way letting the user choose what they see
becomes justified. My first impression of gimp's interface is that
it's pretty clean, though; it doesn't seem to be crowded enough to
warrant anything like that.

>  Anyway, in UI design there is a fine line between usefulness and
>  meaningfulness.  GIMP originally provided a plugin API (and later
>  scripting APIs) so that users could easily automate their own set of
>  "common tasks".  The next step is finding a way to integrate these user
>  defined tasks in to the UI (other than as menu items, and specically in
>  the toolbox or some dialog similar to it) so that the end user defines
>  the meaningfulness of the components on display.

Still, it's drawing primitives. To date gimp remains the only image
editing program that I personally have ever used where I could not
figure out how to draw a box on my own. A box. And it seems to me to
be a fact that a significant number of people have this same problem,
because, again, it's a question in the FAQ. People wonder how to draw
boxes enough that it has to be mentioned in the FAQ. If that doesn't
say "hey it's time to make this feature a little more obvious", I
don't know what does.

>  So, your request sounds simple enough but turns out to be really hard to
>  do in a way that is both meaningful and useful to all users.  Part of
>  the reason is technical (how do you implement the general case of adding
>  a new button to the Toolbox for anyone who needs a really simple "new"
>  tool?) and part is political (why do you get your common tool but
>  photographers don't get a "redeye removal" tool? Which leads back to the
>  technical problem of implementing a general case solution.)

Photographers don't get a redeye removal tool because "how do I
correct redeye problems" is not a question in the FAQ. A general case
solution to drawing primitives is to put a primitive drawing button in
the tool bar, and when you press it, you can draw primitives. It does
not require you to allow any old plugin to place buttons in the
toolbar, nor does it require customizable toolbars. It only requires
one additional button for a frequently asked about, very basic
feature.

>  In summary:  implementing "a" solution is much easier than implementing
>  the "right" solution.

The goal is to be able to draw primitives without having to select ->
fill -> deselect -> cut. There is not a popular graphics program in
existence that requires these steps to draw primitive shapes such as
boxes. It's no more complex than that. "A" solution is to add a
simple, basic primitive drawing tool to gimp. Coincidently, that is
also the "right" solution -- it perfectly fills the requirements of
the goal. I'll draft up a spec some time. It may turn out to be
acceptable, it may not. I'll keep it simple.

Jason
_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Reply via email to