On Wed, Apr 30, 2008 at 1:55 PM, Jason Cipriani
<[EMAIL PROTECTED]> wrote:
> 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.
I say this again later: it's only a two step process.
(make sure that you have keyboard shortcuts assigned to edit->stroke
selection and edit->fill with FG, for best speed)
1. make your selection, using rectangle select, ellipse select, or
polygon select (new in 2.5)
2. press the appropriate shortcut key (stroke selection for unfilled,
fill with FG for filled). You can even do both, to get a filled shape
The advantage of this is of course, you can draw complex shapes
easily; for example drawing the outline of a paper with bites out of
it: box select, several subtractive ellipse selects, stroke.
My understanding from what you have written is that you don't use
keyboard shortcuts much; I suggest learning. You needn't go as far as
I did, completely redesigning the keyboard shortcuts, every time you
can use a keyboard shortcut will save you much more time than
navigating directly to any tool, no matter how suited it is for your
> 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.
This is known as 'edit->stroke selection' :)
> > 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).
GIMP doesn't, mainly because the main developers largely regard
'hiding functionality' as a disadvantage.
The palette buttons have been requested several times, and the answer
has always been 'we won't do that because it's a bad idea.'
> 3) I strongly believe that all image editing programs should have a
> superset of the UI functionality of mspaint.
MS paint, humble as it is, is not a image editing program. It is a
drawing program. You're comparing apples and oranges, so the merit of
this belief is not obvious.
If you were to say 'every painting program should be able to do
everything that MSPaint allows you to, readily' I would agree
> 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.
I agree completely.
> > 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
> > 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.
You can already do this, and it has been mentioned to you how:
tobias said "That's already there, have a look at: Edit -> Stroke Selection...
BTW, the answer in the FAQ for ellipses is suboptimal. Just make your
ellipse selection and edit->stroke selection.
> 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.
Please try what I have mentioned above before continuing with that.
Gimp-user mailing list