Drawing simple shapes.

[jason cipriani-2]

I need to draw a circle and a box, outlined in black, preferably
without erasing the background underneath the shape. How do I do this?

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

[jason cipriani-2]

On Tue, Apr 29, 2008 at 12:43 PM, Jason Cipriani
<jason.cipriani@...> wrote:
> I need to draw a circle and a box, outlined in black, preferably
>  without erasing the background underneath the shape. How do I do this?

I found the answer in the FAQ:

Use the elliptical select tool, hold down CTRL key to constrain as
circle, fill the selected area with new color, right click on selected
area, choose SELECT, SHRINK, shrink selection by whatever number of
pixels you want your circle width to be, right click again in selected
area, choose EDIT, CUT. Voila, one beautifully antialased circle.

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?

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

[Martin Nordholts-2]

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
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[jason cipriani-2]

On Tue, Apr 29, 2008 at 1:03 PM, Martin Nordholts <enselic@...> 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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Martin Nordholts-2]

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
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[Nathan Lane]

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 <jason.cipriani@...> wrote:

On Tue, Apr 29, 2008 at 1:03 PM, Martin Nordholts <enselic@...> 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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

--
Nathan Lane
Home, http://www.nathandelane.com
Blog, http://nathandelane.blogspot.com
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[_budman_]

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

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

[Michael J. Hammel]

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.
--
Michael J. Hammel                                    Principal Software Engineer
mjhammel@...                           http://graphics-muse.org
------------------------------------------------------------------------------
The Dixie Chicks for President!
     -- Anyone but Bush in 2004 --

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

[jason cipriani-2]

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

I do have a pretty clear and simple vision of making primitive shape
drawing easier. I looked at the example specs in the Wiki too. I'll
tell my hypothetical friend and see what he has to say about coming up
with a real spec in the very far, distant future.

The real goal is nothing more than to be able to draw primitives, such
as boxes, without having to go through a convoluted process of select,
fill, shrink, cut.

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 would
also get the job done. Adding a button to the tool palette 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.

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

[Tobias Jakobs-2]

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

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

[Michael J. Hammel]

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                                    Principal Software Engineer
mjhammel@...                           http://graphics-muse.org
------------------------------------------------------------------------------
You're life can be a wonderous journey, if you don't spend all your time
trying to drag someone else through it with you.  -  Michael J. Hammel

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

[jason cipriani-2]

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
<mjhammel@...> 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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[David Gowers]

On Wed, Apr 30, 2008 at 1:55 PM, Jason Cipriani
<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
>  <mjhammel@...> 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
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[David Gowers]

On Wed, Apr 30, 2008 at 2:53 PM, David Gowers <00ai99@...> 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 )
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

[dapperhoo]

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
_______________________________________________
Gimp-user mailing list
Gimp-user@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user