Jason Cipriani wrote:

I have a second question. If "how do I draw a box?" is a "frequently asked question", why isn't there a "draw a box" button on the tool palette in GIMP? Is there some historical reason?

Hello

There are a couple of reaons, some of them partly overlap:

* It is possible to draw shapes already (using the techique described).

* It is a big UI task to define exactly how drawing tools should work and how they should interact with existing tools and workflows in a good way.

* No one with the right competence has yet found enough interest in working on this.

Best regards, Martin Nordholts

Jason Cipriani wrote:

Hypothetically speaking, if somebody were to sit down and try to work on this in the far, far future, it seems like there would only be two choices, both of them fairly straightforward (I'm new to gimp but AFAICT there's no vector-graphics layers so both choices end up with rasterized shapes).

1) It interacts with everything the same way the paint brush and pencil do. Draw squares, circles, etc., directly on to current layer. UI controls are similar to other paint programs... dragging boxes, etc.

2) It behaves the same way a text layer does. Draw squares, circles, etc. to new "primitive shape layer" (or whatever), and they can be edited, scaled, rotated, whatever afterwards (this gives similar functionality to vector-based squares and circles and things).

Thank you for the input.

If someone sits down and writes a detailed specification* that gains popularity on the gimp-developer mailing list, chances are quite high that a hacker will eventually implement this. The daunting task is not writing the implementation itself, the daunting task is figuring out all the details.

BR,
Martin Nordholts

* An example specification: http://gui.gimp.org/index.php/No_image_open_specification

You're right that there aren't vector graphics layers, per se. However there are path layers, which can be treated like vector although they themselves don't have fill or stroke colors or patterns - if you change a path and you want to change the stroke or whatever, you have to do it manually.

On Tue, Apr 29, 2008 at 12:24 PM, Jason Cipriani wrote:

On Tue, Apr 29, 2008 at 1:03 PM, Martin Nordholts wrote:

There are a couple of reaons, some of them partly overlap:

[snip]

* It is a big UI task to define exactly how drawing tools should work and how they should interact with existing tools and workflows in a

good

way.

[snip]

Hypothetically speaking, if somebody were to sit down and try to work on this in the far, far future, it seems like there would only be two choices, both of them fairly straightforward (I'm new to gimp but AFAICT there's no vector-graphics layers so both choices end up with rasterized shapes).

1) It interacts with everything the same way the paint brush and pencil do. Draw squares, circles, etc., directly on to current layer. UI controls are similar to other paint programs... dragging boxes, etc.

2) It behaves the same way a text layer does. Draw squares, circles, etc. to new "primitive shape layer" (or whatever), and they can be edited, scaled, rotated, whatever afterwards (this gives similar functionality to vector-based squares and circles and things).

Are both of those choices satisfactory? They seem simple and flow well with the existing GUI, unless there is something that I'm overlooking.

I ask because if I ever happened to meet the aforementioned hypothetical person who may work on this feature in the distant future, I'd like to give them some useful design hints.

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

Nathan Lane wrote:

You're right that there aren't vector graphics layers, per se. However there are path layers, which can be treated like vector although they themselves don't have fill or stroke colors or patterns - if you change a path and you want to change the stroke or whatever, you have to do it manually.

I've used a plug in for shapes - shape-path-0.91.scm

http://registry.gimp.org/node/59

It works great, but the cords and sizing need to be manually entered. It creates a stroke path using different shapes, with optional fill and/or line colors.

Not sure if this would be similar.

Regards Rich

On Tue, 2008-04-29 at 14:24 -0400, Jason Cipriani wrote:

AFAICT there's no vector-graphics layers so both choices end up with rasterized shapes).

Paths are vector oriented objects in the GIMP. They aren't associated with specific layers so the path is not included directly in compositing (currently). There isn't any reason why vector effects (fills, strokes, etc.) couldn't be applied to the path as some kind of metadata and then associate a path with a specific layer as part of the compositing process.

I would think (based on my limited knowledge of the subject) that GEGL would make this easier in 2.6.

1) It interacts with everything the same way the paint brush and pencil do. Draw squares, circles, etc., directly on to current layer. UI controls are similar to other paint programs... dragging boxes, etc.

In the current release you could implement a tool that simply drops one of a set of default shapes into the canvas. The shapes would be based on paths. Essentially this tool is nothing more than a convenience item for creating a path manually.

This could probably be implemented as a plugin as well, though if you did that I don't think (but am not sure with 2.4) that you can place that as an icon in the Toolbox.

FWIW, my GFXShapes plugin will do vector shapes without paths, but you can save the shapes as presets (re: files). Presets are not saved as part of the image file, however. GFXShapes was written for 2.2 because I really disliked the interface to GFig at the time. I think a plugin or integrated tool based on paths is a better solution now, however.

Am Dienstag, den 29.04.2008, 17:11 -0400 schrieb Jason Cipriani:

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.

That's already there, have a look at: Edit -> Stroke Selection...
Regards,
Tobias

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.

That would
also get the job done. Adding a button to the tool palette

This turns out to be harder than it sounds. See below.

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. At what point do you decide a button for one person should *not* be added because someone else doesn't use it. 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.

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.

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.

There was a plugin at one time that attempted to do just this, but I don't think it was maintained for the 2.4 release. At least I haven't heard of it recently. I haven't heard if 2.6 is scheduled to allow plugins to insert themselves into the toolbox. It would certainly be a nice feature to consider. But such a feature would undoubtedly require preferences configurations for setting which plugins/filters/etc end up in the toolbox based on user choice, along with changes to the plugin/scripting APIs to designate icons for use in the Toolbox. Lots of things have to be considered to get this done right.

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.)

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

"Michael J. Hammel" wrote

"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. At what point do you decide a button for one person should *not* be added because someone else doesn't use it. 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. "

I'm not interested in that peculiar function, but ....will be no possible in the toolbox have a "default" group of icons, and the possibility for tool as that available now but with the option to add till X more ?

(as example from a ipotetic "customize toolbox" preference option,)

So who will be interested to drawing border may get is tool there, while others may add instead some plugin "tool " more useful for their workflow (

Too much icons and tools are a problem only if all displayed to overcrowd the GUI, but if just available (as from "customize toolbox" preference option) they may become added features that may be useful.

Alchemie Foto\grafiche
---------------------------------
Tante idee per la salvaguardia del pianeta su Yahoo! for good.

On Wed, Apr 30, 2008 at 1:55 PM, Jason Cipriani 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 with border.

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 needs.

That said:

On Tue, Apr 29, 2008 at 6:10 PM, Michael J. Hammel 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 completely

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 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.

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.

HTH, David

On Wed, Apr 30, 2008 at 2:53 PM, David Gowers wrote:

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.

I want to make myself clear, I would support the idea of shape drawing tools (box, ellipse, polygon), providing they have the following functionality:
1. Drawing mode+opacity, since it is a paint tool. 2. Choosing between FG,BG,Pattern, and No fill 3. Enabling or disabling antialiasing 4. Enabling or disabling stroking (so you can just quickly draw a filled polygon, say, with no edging.) 5. UI should be based on their respective selection tools -- eg the resizing of a box or ellipse, or editing of a polygon, should be operated completely identically to their selection counterparts.

6. These tools are hidden by default (use Tools palette to un/hide or reorder tools)

Point 6 is mainly because.. GIMP is not a drawing program. (much as I would like it to be :), I do agree that you should be able to do basic drawing of the kind you want in it. I would use these tools myself; I acknowledge that I'm not the target audience of the GIMP, nor are you apparently (see
http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision )

David Gowers wrote:

I want to make myself clear, I would support the idea of shape drawing tools (box, ellipse, polygon), providing they have the following functionality:
1. Drawing mode+opacity, since it is a paint tool. 2. Choosing between FG,BG,Pattern, and No fill 3. Enabling or disabling antialiasing 4. Enabling or disabling stroking (so you can just quickly draw a filled polygon, say, with no edging.) 5. UI should be based on their respective selection tools -- eg the resizing of a box or ellipse, or editing of a polygon, should be operated completely identically to their selection counterparts.

6. These tools are hidden by default (use Tools palette to un/hide or reorder tools)

Point 6 is mainly because.. GIMP is not a drawing program. (much as I would like it to be :), I do agree that you should be able to do basic drawing of the kind you want in it. I would use these tools myself; I acknowledge that I'm not the target audience of the GIMP, nor are you apparently (see
http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision )

Personally I have not given this issue a great deal of thought, but if you want to attack from the angle of product vision, I think there is a clear need for such tools. Consider the bullet point in the vision that states: "GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements;"

Think about the types of tools necessary to create "user interface elements" or "graphical elements of web pages." These types of graphics very often are based around fundamental geometric shapes. Sometimes GIMP seems confused about its own identity. It neither wishes to be like paintbrush, nor a photo editing program like say Irfanview (not a great example), or a pure artistic program like pixia. It doesn't like to be compared with Photoshop, which can do everything but slice bread. So what then is it?

Yes, I understand that is what the vision is all about. Well, my point is, GIMP is supposed to be a high level tool suitable for several distinct graphical/artistic endeavors and I don't see why comparisons to Paintbrush or any other limited program are all that valuable. GIMP has to be a jack of all trades to meet the vision proposed, you simply can't put it in a single category nor be disturbed if it integrates functionally across broad boundaries. The GIMP is not a "type" of program. Furthermore, you should be cautious in saying what the GIMP isn't. How can you say it is not a drawing program when much of what it is meant to do necessarily involves drawing? If you mean it is not a paintbrush clone, then I agree, but that doesn't mean it shouldn't do everything paintbrush does. Whether it does or does not is more or less irrelevant since the developers seek to provide some set of general functionality, not compare it to other software, and rightfully so.

If you hide a button, you may as well not have it. Those of us comfortable with computers can always find a way to accomplish what we need, however tedious or obscure it might be. The button is not for those savvy enough look for it in the tools palette, but for those novice users who want to draw a box or ellipse and can't figure out how to do it.

IMHO,

Ben

Hi Ben,

On Wed, Apr 30, 2008 at 3:50 PM, Ben Walker wrote:

functionally across broad boundaries. The GIMP is not a "type" of program.

Definitely.

Furthermore, you should be cautious in saying what the GIMP isn't. How can you say it is not a drawing program when much of what it is meant to do necessarily involves drawing? If you mean it is not a

Because it is not a drawing program. MSPaint is a drawing program. Painter is a drawing program. Krita is a drawing program. Photoshop is not a drawing program though it allows drawing, and similarly, GIMP is not a drawing program although it allows drawing.

It's just about focus. And I believe it's fairly clear that GIMP is focused on editing, not creation.

paintbrush clone, then I agree, but that doesn't mean it shouldn't do everything paintbrush does. Whether it does or does not is more or less irrelevant since the developers seek to provide some set of general functionality, not compare it to other software, and rightfully so.

If you hide a button, you may as well not have it. Those of us

Please note that the tool would be visible in the menu ('Tools' menu), so it would still be discoverable.

comfortable with computers can always find a way to accomplish what we need, however tedious or obscure it might be. The button is not for
those savvy enough look for it in the tools palette, but for those novice users who want to draw a box or ellipse and can't figure out how to do it.

Yes, I agree.
I want the toolbox to automatically adjust icon size to accommodate the tool icons shown in a reasonable amount of space. This will help encourage the user to hide tools they don't use, since the icon size can increase then.

Hi,

On Wed, 2008-04-30 at 09:43 -0400, Jason Cipriani wrote:

I'm reading what you are all saying and I do firmly believe that an obvious method of drawing primitives would be a reasonable and beneficial addition to GIMP.

Have you tried the GFig plug-in yet? It provides an easy method to draw a variety of shapes with the ability to specify the stroke and fill type.

Sven

Hi Jason,

On Wed, Apr 30, 2008 at 11:32 PM, Jason Cipriani wrote:

On Wed, Apr 30, 2008 at 9:59 AM, Sven Neumann wrote: > On Wed, 2008-04-30 at 09:43 -0400, Jason Cipriani wrote: >
> > I'm reading what you are all saying and I do firmly believe that an > > obvious method of drawing primitives would be a reasonable and > > beneficial addition to GIMP.
>
> Have you tried the GFig plug-in yet? It provides an easy method to draw > a variety of shapes with the ability to specify the stroke and fill > type.

No I have not. I'm looking on the internet now; is this shipped with the latest version of GIMP? If not, do you know where I can grab it? (Sorry, GIMP is not installed on the machine I'm using right now). I'm reading the user manual for it, it looks pretty great.

You can find GFig in Filters/Render. It's a little surprising at first, how you make a change to a shape and it is promptly redrawn on canvas :) I was looking for an 'OK' button until I realized this :)

HTH, David

On Wed, 2008-04-30 at 09:55 -0400, Jason Cipriani wrote:

Would you recommend using Krita for image creation? Despite the fact that "image authoring" is a point listed in the very first sentence on gimp.org's main page, and that "painting" *is* the first bullet point category on the GIMP info page, from what you say and what I see GIMP does not actually seem to be the right tool for "producing icons, graphical elements of web pages and art for user interface elements"

I'd have to disagree with this, and my most recent book on the GIMP goes to some effort to show you why. There are multiple chapters on graphical elements for web pages and designing user interface elements. I didn't cover icons because I'm not particularly good at icons and don't create them very often. But I've seen some extremely good icons developed with the GIMP.

Just because there isn't a "one button click box" feature doesn't mean GIMP can't, or shouldn't, be used for this kind of work. In fact because it provides lower level access to processes like creating primitive shapes (specifically paths), it's ideally suited for this type of work.