Re: [Gimp-developer] GLIB version error while compiling GIMP with MacPorts

2011-04-14 Thread Akkana Peck
Tim Chen writes:
 Note that one has to install gtk2 using command below to avoid some weird 
 dependency problems

Most Linux people have to recompile gtk2 (and its dependencies) to
build GIMP now too.

 ImportError: could not import pygtk

Did you build python-gtk? It's a separate package, with its own
dependency set.

Last time I watched someone try to build python-gtk from Macports,
it turned out to be a lot easier just to download the tarballs and
build and install them by hand. Macports wanted to bring in all
kinds of crazy dependencies, including recompiling X and three
different versions of Perl, all of them built from source. But
maybe they've fixed the dependencies since then.

Gimp-developer mailing list

[Gimp-developer] IRC session on how to build GIMP

2011-04-13 Thread Akkana Peck
Are you a GIMP user or Summer of Code student who's been wanting to
get involved, but having trouble building, or a bit intimidated by
the build process?

I'll be running a session on IRC to help anyone build GIMP on Linux,
as part of the OpenHatch Build it project.

The session will take place on #gimp on (also known as
GimpNet), on Fri, Apr 15, 0300 UTC -- that's Thursday night in the
Americas. To convert to your time zone, run this command on your
local machine:

$ date -d 'Fri Apr 15 03:00 UTC'

Or try this link:

This is a time that's usually fairly quiet on #gimp -- European
users don't fret, since it's pretty easy to get help there during
more Europe-friendly time zones. I'll hang around for at least two
hours; that should be plenty of time to build GIMP and all its

Note: The #gimp IRC channel was recently under attack by trolls, and
it's possible that it may not be usable at the time of the session.
I've also posted this on my blog, and in case of trolls I'll update
the blog page with the name of an alternate channel to use.

If you want to get your system set up ahead of time, I've put the
instructions needed to build on Ubuntu Lucid and other older Linux
distros here: Gimp Building Tips (for Linux). I might be able to
offer a little help with building on Macs, but no guarantees.

Mac and Windows users, or people running a very old Linux distro
(more than a year old) might want to consider an alternate approach:
install Virtualbox or VMware and install Ubuntu Natty Narwhal
(currently still in beta) in a virtual machine.

Of course, this isn't the only time you can get help with building
GIMP. There are folks around on #gimp most of the time who are happy
to help with problems. But if you've been meaning to get started and
want a good excuse, or you've been holding off on asking for help ...
come hang out with us and try it!

Gimp-developer mailing list

Re: [Gimp-developer] Color circles (Thank you.)

2011-02-28 Thread Akkana Peck
Patrick Horgan writes:
 I'm sitting here whipping out a picture of a RGB Venn diagram with text 
 labels with a recent pull from trunk in single window mode.  [ ...  ]
 p.p.s The venn diagram is done with 5 layers.  Top to bottom:

I agree -- it's great how easy GIMP makes this task.

I have a script for that, which I wrote mostly so I didn't have to
position the three circles by hand:

I use three layers, in Addition mode, but that requires that the
background layer be black. For subtractive colors, use Subtract mode
and a white background.

Gimp-developer mailing list

Re: [Gimp-developer] current git version: weird behavior in a detached menu

2010-09-10 Thread Akkana Peck
Olivier writes:
 Git version compiled today on Ubuntu 10.04. Using a right-click in the Image
 window, I detach the Image - File - Create menu. In this detached menu,
 the menu entries work as customary. However, the simple entries, for example
 Screenshot, have no other effect than to display a comment iin the bottom of
 the Image window.

That's true for 2.6.8 as well. Sometimes they work, mostly they don't.
It might be something to do with the GTK (2.20.1) installed on
10.04. I really miss those tear-off menus.

Gimp-developer mailing list

Re: [Gimp-developer] Addressing one of the gimp vision items...easy installation of plug-ins

2010-05-14 Thread Akkana Peck
Martin Nordholts writes:
 On 05/14/2010 04:13 PM, Rob Antonishen wrote:
  - GIMP should be easily extensible by the average user: one
  click-installation of plug-ins
 I agree installation of plug-ins is a pain, but I'm not aware of anyone 
 planning to work on improving the situation.

Writing a file handler like Rob describes sounds easy -- if all you
care about is script-fu.  The hard part would getting Python and C
plug-ins installed for users (especially Windows users) who don't
have Python, PyGTK or a C compiler.

Gimp-developer mailing list

Re: [Gimp-developer] Trying to Make a Plug-In

2010-04-23 Thread Akkana Peck
Callie writes:
 Hey guys,
 I have very limited experience in programming, and none at all with making
 plugins, but I want to make a plugin that would make my life a whole lot
 Unfortunately, it seems that all the information regarding this process is
 written for people who are experienced in programming or writing plugins or
 such, and is unintelligible to me.

I wrote a pair of articles a while back for Linux Planet on writing
GIMP plug-ins in Python. Although there wasn't space to teach
Python from scratch, I tried to write even for people who don't
have much programming background: (part I) (part II)

 My first question would be, what language should I be using and how do I set
 it up so that it will work.

Assuming you have GIMP Python support already installed (do you have
a Filters-Python-fu menu?), most people find Python easier to read
than Script-fu. But Script-fu does have the advantage that there are
lots of scripts available to copy, and you can count on it already
being installed.

Gimp-developer mailing list

Re: [Gimp-developer] Text color change

2010-03-17 Thread Akkana Peck
Thales img writes:
 Is there any way to change the color of part of a text? Like this:
 This wordis red
 I'm asking 'cause if there isn't an easy way is something to think about.

Probably the easiest way is to use bucket fill and click on each
of the letters. Note that that will change the layer into a graphics
layer and lose the special text information, like font and size.

A more elaborate, but more flexible, way, is to make a new layer
on top of your text layer. Make a selection in that layer covering
whatever part of the text you want in a different color (e.g. a
rectangle covering only that word). Fill the rectangle with your
desired color. Then, in the Layers dialog, set the mode of the
new layer to Lighten Only. If your text was black, that will turn
the word your desired color. If you started with a different color
of text, you might need a different layer mode (experiment with all
of them).

Depending on your background color, this might also change some of
the background around the text, but there are some ways to get arond
that. Merge down on the layer will merge it only with the text layer
below it, or you could use the text layer as a mask to mask off
everything but text in the color layer. The best approach depends
on exactly what effect you're trying to achieve and what colors
are involved.

Gimp-developer mailing list

Re: [Gimp-developer] remove layer should not force you to last selected layer

2010-03-05 Thread Akkana Peck
Luiz Felipe Moraes Pereira writes:
 Also I do not mind much about not having a selected layer after 
 the deletion of a layer. But the forced viewer scroll down( or up ),
 depending of the last selected layer is a problem.

This used to annoy me a lot, because I frequently want to delete,
say, the top 5 layers. But once I figured out what it was doing,
I developed a habit of clicking on the layers I want to delete in
sequence before deleting. For instance, click on the 5th layer from
the top, then the 4th, and so on until I get to the top; then click
Delete 5 times. It sounds tedious but it doesn't take long at all --
certainly it's a lot faster than scrolling back up each time.
Try it -- you may find that it solves the problem.

Gimp-developer mailing list

Re: [Gimp-developer] moving windows in the git version

2010-02-17 Thread Akkana Peck
Olivier writes:
 For several weeks now (I compile the git version every Monday), the windows
 in normal mode (i.e. multi-window mode) behave in a weird way: I place them
 where I want them on one virtual screen, and then I move to another one
 virtual screen. When I come back, the windows have moved to a different
 place, always the same.

That also has a workaround, if you want to patch your local version
so you can use gimp in the meantime.

Gimp-developer mailing list

Re: [Gimp-developer] GIMP GIT: window hints and text move

2010-01-25 Thread Akkana Peck
Michael J. Hammel writes:
 I start 2.7 in one
 workspace, then switch to another, then back to the GIMP workspace.  The
 toolbox and docks are gone - I can't find them in any workspace.  Only
 the image window remains visible.  Tabbing doesn't change anything.
[ ... ]
 I searched but the closest I found was #595708.  Not sure if this is
 related or not.

Bug 556896.

 With GIMP 2.6 Metacity works fine.  Seems a bit of a stretch to force
 people to change window managers with 2.7 just so it doesn't do this.

Agreed. It works if you use Utility window as the hint for the
toolbox and docks, but then they stay on top of the image window
unless you hide them completely with Tab.

Gimp-developer mailing list

Re: [Gimp-developer] Tool Presets (was easily switch to last used tool)

2010-01-10 Thread Akkana Peck
 On Sat, Jan 9, 2010 at 8:21 PM, peter sikking wrote:
  so per-tool presets would be the solution for your case

Alexia Death writes:
 May it be noted that the tool presets of this nature already exist.
 they are just terrible to use. those little buttons and menus in tool
 options suck. So perhaps we could just start with making those tool
 presets usable?

The biggest problem I have with the current tool preset UI is that
Save and Restore look almost identical, but Save is destructive.

More than once, I've clicked on Save intending to choose (Restore) one
of my presets. A menu pops up with a list of the current settings,
so I choose the one I want -- and I end up overwriting that setting.

And there's no Undo, so now I have to stop what I'm doing, go figure
out what those settings were, set them by hand, Save them again, and
finally I can get on with editing the image.

I finally learned never to click either of those buttons without
first hovering over it and waiting for the tooltip, to make sure
it's absolutely positively the right button.

Without any real redesign, it would help a lot to have a heading on
that menu that says Save options in bold -- so it's possible to
tell that you're about to overwrite something before you do so.

Gimp-developer mailing list

Re: [Gimp-developer] We should go for a single-window mode in 2.8

2009-09-21 Thread Akkana Peck
peter sikking writes:
 hey guys,

 I have now blogged about the single-window mode:

I was really getting excited about getting tabs in the image
window (the image parade idea would achieve a similar function),
since it would make it so much easier to group similar images together
when I open them all at once.

But it looks like if I want that, I have to switch modes to
single window mode, and then I give up two important features:

1. The ability to open an unrelated image quickly in another
window. For instance, I'm editing 7 photographs from the same trip,
and suddenly I need to make a quick change to a 250x50 web icon,
placing that window near the browser to see how it will look.
It doesn't make sense to open that image in the big window I'm
using for the photos.

2. The ability to open a second view on the image I'm editing,
zoomed to whatever level I need and placed somewhere that's not on
top of the current image. It's fine if second views are view-only
Polaroids; but if it's always zoomed out and placed partially on
top of the current image, it won't serve the function that Views
currently serve now.

Is there any chance you might allow those features to coexist with
tabs / image parades? It looks like you'll still allow the toolbox
and docks to be torn off; please consider allowing separate image
windows and views too.


Gimp-developer mailing list

Re: [Gimp-developer] Panels disappearing when changing workspace

2009-08-06 Thread Akkana Peck
Alexandre Prokoudine writes:
 On Thu, Aug 6, 2009 at 1:16 AM, Sven Neumann wrote:
  I'd rather open a bug-report against your window manager.
 That would be Metacity, which is declared getting obsolete and has
 over 400 (IIRC) not closed bugs .

It's been reported against at least 4 different window managers
so far: metacity, xfce, openbox and windowmaker. It's not just
metacity.  It makes gimp quite a bit more difficult to use under
those window managers -- it's what's been keeping me from using git
GIMP for anything more than quick tests.

There are also some reports of similar behavior on Windows;
I'm not sure whether it really is the same issue, not being
familiar with the Windows problem, but Michael Schumacher
thought so when he marked bug 566196 a dup of 556896.

Gimp-developer mailing list

Re: [Gimp-developer] Improved brush editing interface mock-up

2009-07-26 Thread Akkana Peck
 Martin Nordholts wrote:
  I would just like to point out that the smallest screen size supported
  by GIMP is 1280x1024, so we don't need to make 1024x768 work or look

SHIRAKAWA Akira writes:
 Yes, I've read that many times and I would agree with it too since 
 anything lower than that resolution is rather old gear.

Not at all -- there are thousands of netbooks sold in this year
with 1024x600 resolution. I'm sure nobody considers a netbook
an ideal graphics platform, but it's nice to be able to do a
quick edit when you're traveling. And lots of small non-netbook
laptops still have only 768 pixels vertically.

But more important, 1024x768 is the max resolution supported by most
projectors, so anyone trying to teach a GIMP class or give a talk
needs that resolution.  That may be some people's first exposure to
GIMP, so I hope the UI doesn't change to be unusable on projectors,
one of those programs where windows have a minimum height and
disappear off the bottom of the screen. Currently GIMP works fine
at 1024x768.

Gimp-developer mailing list

Re: [Gimp-developer] Scrollwheel actions by default?

2009-07-25 Thread Akkana Peck
Jernej Simončič writes:
 I'm all for it - in my experience, the wheel is useless for scrolling
 the images (partially because it's limited to single direction only),
 but works very nicely for zooming in and out (and if you combine this

I use the mousewheel for scrolling quite often, especially when
I'm making a selection with polygonal select or quickmask so I'm
zoomed way in to see pixel details.

I find the - and +/= keys convenient for zooming in and out (and
1 for going to fullsize), so I've never needed mousewheel zooming.

Gimp-developer mailing list

[Gimp-developer] API for bringing up a Save dialog

2009-05-29 Thread Akkana Peck
 On Fri, May 29, 2009 at 3:59 PM, Ryan Krauss wrote:
  pdb.gimp_xcf_save(1, img, drawable, xcf_path, xcf_path)
  pdb.gimp_file_save(img, drawable, xcf_path, xcf_path)

That leads into something I've been needing from Python:
I'd like a way of bringing up a Save-as or Export-as dialog
from a Python script. There's no API for this currently, as far
as I can tell. If I call pdb.gimp_file_save like this:

pdb.gimp_file_save(img, newimg.active_layer, pathname, pathname,

it goes straight to the jpeg save dialog, or the png save dialog,
or whatever, skipping the dialog that would let the user change the
filename. I'd like to set the filename, but then give the user a
chance to change it and to see or change where it's being saved.

Would be be possible to add an API for this, or maybe an optional
argument in gimp_file_save and the corresponding _export function?
I can try to implement it and submit a patch, but I'd like to know
if such an API would be acceptable, and how you'd want it to look.
For instance, maybe

pdb.gimp_file_save(img, newimg.active_layer, pathname, pathname,
   run_mode=0, show_save_dialog=True)

Or, possibly, should the code be changed so that it always shows the
save-as dialog if run_mode is interactive? It would change the
behavior of existing scripts ... but only in the interactive case.

David Gowers writes:
 The recently introduced Export framework may end up simplifying your
 situation.. It considers a file 'clean' only when it has just been
 saved to XCF (or xcf.gz, etc) format, and introduces a separate
 'Export' action for producing a 'rendered result' in eg. PNG format.

In the new framework, will gimp_file_save() fail if the filename isn't
xcf?  Will scripts need to be rewritten to call gimp_file_export
instead? If authors have to rewrite their scripts anyway, making a
small change to what run_mode=0 does at the same time might not be
much of a problem.

Gimp-developer mailing list

Re: [Gimp-developer] API for bringing up a Save dialog

2009-05-29 Thread Akkana Peck
Sven Neumann writes:
 On Fri, 2009-05-29 at 10:18 -0700, Akkana Peck wrote:
  I need to show the dialogs because the plug-in needs to save a
  file (that's the whole point of the plug-in) and it seems like
  bad UI to pop up the JPEG save dialog without ever showing the
  user where the file is being saved, or offering them a chance
  to save it somewhere else.
 Then please add a sane user interface to your plug-in and pop up a
 file-chooser. The PDB was designed to allow plug-ins and scripts to call
 procedures in GIMP, not to pop up specific user interface elements. It
 is totally not suited for this kind of usage.

I'm confused -- you say I should pop up a file chooser, then you
say that's not what the PDB is for. Is there a non-PDB way to do
this from a plug-in?

Popping up a file chooser is exactly what I'm trying to do.
But I'd ideally like it to be the gimp file chooser with the image
file types, not a generic GTK file chooser (just for consistency,
because the GIMP dialog is what the user expects to see elsewhere
in gimp). That's why I was asking for an API to do that.

Gimp-developer mailing list

Re: [Gimp-developer] [wish] alignment rotation

2009-05-14 Thread Akkana Peck
Jay Smith writes:
 My desire would be for:
click (on first point)
click (on second point to finish the line)
do a keystroke command that can be accomplished with ONE hand
  to execute the task (I would prefer not to have to hit the Enter

You could perhaps do this with a plug-in:

- Use the Paths tool
- Click on first point, then on second point
  (now you have a straight-line path with two endpoints)
- Run a plug-in (which you can assign to any key you like)
  that gets the current path endpoints, rotates the current layer
  the appropriate amount, then deletes the path.

It would be an easy plug-in to write. You would stay in the Paths
tool and not have to switch tools at all.  Would that do what you want?

It would still be a useful feature to add to the Rotate tool, and
that discussion should continue; but since any change to a tool
won't be available until the next major version, this might be
a workaround that you could use right now.

Gimp-developer mailing list

Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-14 Thread Akkana Peck
Liam R E Quin writes:
 5) zoom in on the place where you want to work, a step
at a time, gradually moving the floating selection
 6) when you get to 50% or 100% so you can work, try to remember
why you wanted whatever you pasted.
 Why you think that's a smoother workflow than
 1) paste so floating selection appears on the screen
 2) continue working
 is beyond me.

I've found the paste centers behavior quite useful, and have
recommended it to lots of other people as a quick way to center
a layer (which used to be a FAQ, though less so now that the
align tool exists).

That said, it's hard to see an argument for anyone wanting to
paste to a part of the image that isn't visible. Surely most
people paste because they want to do something with the pasted
layer, which requires it being visible on screen.

Perhaps paste should center within the visible viewport?

Gimp-developer mailing list

Re: [Gimp-developer] RFE: Changing/Remembering/Setting Dialog Defaults for Image... Canvas Size...

2009-04-03 Thread Akkana Peck
Jay Smith writes:
 In the dialog box:
Image... Canvas Size...
 - Layers... The dialog _always_ seems to default to None instead of
 All Layers.  I want to set a default of All Layers.

I too would love this to be remembered. I usually want All
image-sized layers but it gets to be a hassle to change it,
so I usually don't and then find I need to resize the layers later.

Developers: if someone were to make a patch to do this, would it be

If so, would it be better to have it always remember the last
setting, or to introduce a new preference for which setting the
user wants as default for each session?

 - Canvas Size... The 'link' symbol at the top, between the two pixel
 sizes, reverts every time to linked status.  It seems that it has to
 be unlinked every time if you wish to change only one of the
 dimensions of the canvas (or change them differently).  I want to be
 able to have this default to unlinked so that I can change them
 independently without having to click the link/unlink.
 - Canvas Size... The method of measurement always defaults to pixels.
 For my work, it would be easier for me to see/manipulate inches or cm.

I haven't hit those two myself, but if I were to change the Resize
layers option and people thought it was worth doing these two, I
could look into doing them at the same time.

And while we're talking about options I want to change every time:
two more I'd love to have remembered is in the JPEG Save dialog,
Preview and Save thumbnail. I always want Preview (why would
anyone ever move the quality slider and not want to see a preview?)
and I never want EXIF thumbnails, but there's no way to save those
settings. I tend to hack them in my own copy of GIMP, but I'd love
to do a patch for JPEG save that would remember all the options
in the dialog, across sessions. Is there any chance that would be

I know there's a proposal in bugzilla to write a general mechanism
for all plug-ins to remember their settings; but that proposal has
been there through three major releases and there's no consensus
on how to do it, and in the meantime, fixing JPEG save is something
that could potentially help a lot of people.

Gimp-developer mailing list

Re: [Gimp-developer] a good student UI project...

2009-03-29 Thread Akkana Peck
Rob Antonishen writes:
 Why limit it to path stroking?
 It might be more flexible to create a stroke style editor where you
 could visually adjust those attributes including tapers, brush
 spacing, jitter, gradient mapping, and ultimately new features like
 rotation, opacity and scaling (which tapering ultimately is), either
 as start/end values or randomized values.
 These stroke styles could be used either when stroking a path, a
 selection, or just when painting.

It would be SO nice to be able to taper lines when drawing.
It could be handled just like fade out is now; or it could be
handled in Brush Dynamics, adjusting Size with Distance.
(The other attributes you mention would be nice too, but
tapering is the one I've wished for most often.)

Either way the UI would be simple, so it's probably not a good student
UI project, but it sure would be useful as a drawing tool attribute.

Gimp-developer mailing list

Re: [Gimp-developer] Gimp license

2009-01-12 Thread Akkana Peck
So finally, I hereby suggest to move to GPL3 asap.
Comments from any developers appreciated.

Liam R E Quin writes:
 I think I only have half a dozen lines of code in there,
 but in case there's any doubt, it's fine here :)

Likewise for me -- I don't have many lines of code in GIMP
but the GIMP team is certainly welcome to relicense anything
of mine as GPLv3.

Gimp-developer mailing list

Re: [Gimp-developer] Environment suggestion

2008-11-13 Thread Akkana Peck
Rob Antonishen writes:
 I have an older PIII notebook I'm willing to blow away and use just
 for this purpose ... can anyone suggest the shortest path from a blank
 hard drive to a working gimp develpment environment?

Sven Neumann writes:
 It doesn't hurt to put babl and GEGL into /usr/local. Just run configure
 without any extra arguments and things will just work.

There's one more step you'll need in addition to getting gegl and
babl that I didn't see mentioned (maybe I just missed it): gimp
needs quite a long list of build dependencies that aren't installed
by default, especially on Ubuntu which doesn't even install a
compiler. If you follow Martin's suggestion (which I agree with)
of using Ubuntu 8.10 (Intrepid Ibex), you can get the requirements
using one (perhaps very long) line typed in a terminal window.

This command might work, but I haven't tried it myself:
sudo apt-get build-dep gimp

If you try that but still get build errors from missing packages,
try the long version listing all the important packages:

sudo apt-get install build-essential subversion make gcc libglib2.0-dev 
libgtk2.0-dev intltool automake1.9 libtool gtk-doc-tools g++-3.3 libart-2.0-dev 
libtiff4-dev libexif-dev libxmu-dev libjpeg62-dev libmng-dev libpng12-dev 
librsvg2-dev libgutenprintui2-dev libaa1-dev python2.5-dev python-gtk2-dev 
libaa1-dev libxpm-dev libwmf-bin libwmf-dev libgtkhtml2-dev 

By the way, on an older PIII notebook, you may have trouble
with the standard Ubuntu Live CD installs. If the Live CD doesn't
boot or locks up partway through the installation, don't give up,
but try downloading one of the Alternate Installer CD images.

Unfortunately you may also have performance issues with GIMP 2.7
on a machine like that. With anything earlier, a PIII notebook
should be okay as long as you're patient -- the build will take
quite a while, maybe as long as a few hours -- and you don't need to
work with huge images.

Gimp-developer mailing list

Re: [Gimp-developer] gimp print dlg

2008-09-10 Thread Akkana Peck
 thanks for the explaination. I've checked and gimp-print is built with  
 gimp option. Should that alter the dlg I get from gimp file print menu?

Are you building in gimp-print then doing a make install?
Is this the latest gimp-print from ?
Check that make install is really succeeding.

If you already have gimp's built-in gtkprint plug-in, and you also
build gimp-print from the Gutenprint project, you'll probably end
up with two different File-Print... menu entries. One of them
should bring up the Gutenprint dialog, the other, the GTKprint one.

As long as you're building gutenprint yourself, I'd recommend
modifying their src/gimp/print.c: find the line that registers to 
(line 166 in the latest version) and change the name, e.g.

Then you'll be able to tell the the two plug-ins apart and verify
that your gutenprint plug-in is really getting installed.

Gimp-developer mailing list

Re: [Gimp-developer] Should we replace the 'Zoom when resizing image window'-button?

2008-08-10 Thread Akkana Peck
Martin Nordholts writes:
 There is a little button in the upper right corner of each image window
 with the tooltip Zoom image when window size changes.
 I have never used this and I can't figure out in what way it is useful.

It's useful in that it lets you scale the window exactly as big
as you want -- you're not limited to 25%, 33%, 50%, 100% etc.

That said ...

 Does anyone ever use it?

I don't (partly because I always forget it's there). I set the
Resize on zoom preference, and usually scale with the +/-/1 keys.

 I suggest we replace it with a shortcut to the Resize window on zoom
 option which I find much more useful.
 Does anyone have any objections to this? Should some completely other
 feature be accessible through that button?

It seems odd to devote space to toggling a preference like that
... in theory, the current functionality seems more useful since
it lets you do something that isn't otherwise possible. But as
I said, I don't actually use it very often in practice. And it's
not very discoverable. I didn't know from the tooltip what it would
do and only found out by experimentation. It might be clearer if
the tooltip added a few words, e.g. Zoom image to fit window
when window size changes or Zoom image proportionally when window
size changes.

Gimp-developer mailing list

Re: [Gimp-developer] Gimp default brush set contest

2008-07-09 Thread Akkana Peck
Rogier Wolff writes:
 I have a weird obsession. I work with images that are larger than what
 most other people work with.
 So I don't need a 3, 5, 7, 9, 11, 13, 15, 17, or 19 pixel fuzzy
 circle, but I need one that is around 30 pixels wide. Or 50. 

I'm not sure that's all that unusual. With cheap consumer cameras
makng 6 or 8 megapixel images or even more, the standard brushes are
quite small. I've been making a lot of use of the brush scaling
control to make the brushes big enough to be useful on photographs.

Alexia thought 50 was surprisingly large, but remember, brushes
aren't just for painting colors and fine clone jobs -- they're also
useful for running dodge/burn or blur/sharpen over areas of an
image, or painting areasin a layer mask or quickmask. 50 pixels
isn't big at all for jobs like that, and even 190 (the largest stock
round brush you can get right now, Circle(19) scaled to the maximum
of 10x) isn't all that big. Try it against an 8 megapixel photo.

Gimp-developer mailing list

Re: [Gimp-developer] Gimp default brush set contest

2008-07-09 Thread Akkana Peck
I wrote:
 Alexia thought 50 was surprisingly large, but remember, brushes

Oops, that was Valerie, sorry.

Gimp-developer mailing list

Re: [Gimp-developer] Enhancement idea: Snapshot tool for quick comparisons

2008-06-27 Thread Akkana Peck
vabijou2 writes:
 Image - Duplicate is an unacceptable alternative.  The idea is to create a 
 single window that allows the user to cycle through multiple (named)
 in any order he chooses to see large or small changes more readily.  Image
 Duplicate has so many negatives to this process that I don't know where to 

How about this?

The first time, do Copy Visible then Paste as-New Image.
Call this new image the snapshot image.

After that, do Copy Visible then go to the snapshot image and Paste
(then click New Layer).

Now the snapshot image has all the snapshots as layers. To cycle
through you need only turn layers on and off.

Of course, if you did this all the time you could very easily
automate the process: make a little script-fu that does Copy
Visible, checks whether the snapshot image exists, then either
does Paste as New or Paste + New Layer in the snapshot image,
from a single menu item.

Gimp-developer mailing list

Re: [Gimp-developer] Specs for Export/Save User Interface

2008-06-12 Thread Akkana Peck
 3)  Putting Text on a .png (in-place file editing)
 - Open bla.png
 - Text layer created
 - Export to bla.png exporting to currently opened file is 
 admittedly ugly, but
 consistent. The image stays dirty as 
 the layer data
 has not been saved.
 - confirm overwrite protection
 - check result in web browser
 - Modify Text size
 - Export to bla.png again
 - confirm overwrite protection
 - check result OK
 - last finetuning, e.g. brightness
 - Save  dialog pops up, warning of layer data 
 - Convert to PNG (dialog button)layers get merged, image gets saved 
 to bla.png
 and flagged clean.
 - Close no warning here

Two problems/questions on this workflow:

1. Every checkpoint of the file (saving in case of disaster),
something which now is just a Ctrl-S, becomes an operation that
requires going through at least one scary dialog (the overwrite
one) and sometimes two (at least the first time, where the user
has to select the same filename that GIMP already knows).

2. Why would a user use Export for every save except the last one,
then suddenly switch to using a completely different command to save?
How would they learn to do this? Because of GIMP warning them when
they try to quit that the file hasn't been properly saved? Won't
most users say But I just saved it!, click Quit Anyway, and then
go complain to someone about how GIMP often, but not always, says
images haven't been saved when they really have?

This model seems much more confusing for users since they have to
understand a lot more about what makes an image compatible with each
format they might save to. (I know it seems patently obvious to
anyone on this list why adding a text layer is different from doing
a crop, but when you talk to users who mostly edit photos, a lot of
them aren't very clear on differences between image formats.)

Gimp-developer mailing list

Re: [Gimp-developer] proposed solution for: protection from information loss

2008-06-08 Thread Akkana Peck
 Additionally, the 'forced .xcf' behaviour can be quite nagging - consider 
 user experience for a quick Levels adjustment to a photo:
[ ... ]
 Where i agree with you, is that gimp should support the typical workflow
 which centers around a .xcf main document with several regularily updated 
 But that is another topic.

For that workflow, what would be even more useful is to be able to
have a command that could do both: save the current .xcf (.gz or .bz2)
AND, from the same menu item or keystroke, save a copy to a simpler
format. Then you wouldn't have to go back and forth between Save and
Save a Copy every time you make a change, and you wouldn't have to
confirm the copy's filename every time you saved it.

It would be great if it were possible to write a plug-in that would
do that, even if gimp didn't include it natively. It would need to
get the current filename (that's easy already, gimp-image-get-filename)
and also what the last save a copy filename was (not so easy --
I don't think there's an API to get that now, is there?)

 What if Save foo.jpg would actually flatten the image?
 If that was not intended, the user could easily undo and use Export the next 
 Advantage: The result can be seen, with layersalpha being lost. This is much 
 intuitive than textual explanations...

That trains users not to save intermediate results in some cases.
Consider the case where you need to add text to a jpeg with the
result being another jpeg for a website; yet you still might want
to try several different fonts, text strings etc.
I know, you're thinking Why not save the intermediates as xcf?
But if there are only a couple of layers and fifteen minutes of work,
it doesn't always seem worth the extra disk space to save an xcf
in addition to the final jpg.

Gimp-developer mailing list

Re: [Gimp-developer] More intelligent user protection from information loss

2008-06-07 Thread Akkana Peck
Alexia Death writes:
 I'm going to echo my support for this. The nags on saves are 

And often they're not even right -- e.g. The image has
transparency, flatten? shows up on anything with an alpha
channel even if every pixel is fully opaque. All those dialogs
do is train the user to click OK without reading.

Gimp-developer mailing list

Re: [Gimp-developer] EXIF data missing after jpg save

2008-06-05 Thread Akkana Peck
Paka writes:
 the opensuse team that is maintaining gimp/ufraw does not believe that
 exif data is important to the project and do not include support for
 exif.  I questioned stbinner at suse dot de several years ago (iirc)
 and was imformed.  Perhaps several questions/comments from different
 users would convince them otherwise.

If they can't be persuaded, Jim might want to look into jhead's -te
option, which copies exif from one file to another, so you can put
back exif that's been stripped.

Gimp-developer mailing list

Re: [Gimp-developer] A question on Gap -frame modify

2008-05-11 Thread Akkana Peck
Alchemie fotografiche writes:
  1.a  # for bourne and ksh users:

 export GAP_DEBUG
1.b # for csh users
setenv GAP_DEBUG y 
 Now i don't know if i am a bourne, a ksh, or a csh user, i just know (and not 
 as expert) how to use the terminal
 of my distro Ubuntu Hardy Heron.

If you're a Linux user and you don't know (haven't changed it explicitly),
then you're a bash user, which uses the same syntax as Bourne shell.

So use 1.a.

Gimp-developer mailing list

Re: [Gimp-developer] sharefonts dependancy?

2008-05-07 Thread Akkana Peck
 This seems pretty marginal usage. Can anyone advise if removing sharefonts  
 will break fu or any other parts of gimp?

The freefonts and sharefonts packages disappeared from Ubuntu and
Debian quite a while ago (years). Kind of a shame -- there were some
nice fonts in those packages.

Gimp-developer mailing list

Re: [Gimp-developer] change layout of mode menus?

2008-02-17 Thread Akkana Peck
 On Sat, 2008-02-16 at 10:11 -0800, Akkana Peck wrote:
  dialog, which makes the process a lot easier. I've always wished
  I could have something like [a dialog] for the mode on the current layer,
  so I could easily try each layer mode sequentially.

Sven Neumann writes:
 Why don't you just focus the combo-box and use Cursor Up and Cursor Down
 to go through the layer modes? Or use your mouse-wheel?

Honestly, it's because I didn't realize I could use up/down arrows
in option menus without first popping up the menu. :)

That works well for going through modes sequentially. But there
are other common issues a tear-off would solve, like when you want to
go back and forth comparing two modes that aren't near each other
in the menu.

 There are very good reasons why tear-off menus are deprecated. They
 don't solve usability issues but introduce them.

They're deprecated? It figures that something so useful would be.

Fortunately, python makes it pretty easy to work around that.
If anyone besides me wishes for a tear-off modes menu,
you can get one (Layer-Mode dialog...) at:

Gimp-developer mailing list

Re: [Gimp-developer] change layout of mode menus?

2008-02-16 Thread Akkana Peck
I got to thinking some more about this discussion about the mode
list UI. What I've really always wanted for the mode list (but
didn't want to say because it didn't seem like a good general
UI model) is a sort of mode tool: a way to keep the mode
list menu posted so I can change modes on the current layer with
a single click. 

In a way, the mode list is like the font list in the text tool: that
combobox, like the mode option menu, is way too long and unweildy to
navigate, but for font choosing you have another option, the Fonts
dialog, which makes the process a lot easier. I've always wished
I could have something like that for the mode on the current layer,
so I could easily try each layer mode sequentially.

And then I realized that it's actually quite easy to have that now,
with no gtk changes needed. Just write a little script that changes
the current layer's mode to the next one. So here it is:

If you do this layer-changing often, just bind Layer-Next mode
to a key, or use tear-offs to keep the Layer menu posted so you
just need to click on Next mode repeatedly.

And now I no longer wish for some new exotic option menu replacement. :-)

Gimp-developer mailing list

Re: [Gimp-developer] change layout of mode menus?

2008-02-16 Thread Akkana Peck
Bill Skaggs writes:
 Well, it would be very easy to make the layer mode menu
 support a tearoff.  It can literally be done by adding two
 lines of C code.  (I just tested.)

A tear-off Mode menu from the Layers dialog would be lovely, and
would solve every problem I've ever had with that menu.

One possible problem: would Modes from drawing tool options also be
tear-off, and would that be a different Modes tear-off from the one
in the Layers dialog? Would there be a way to tell them apart?

Gimp-developer mailing list

Re: [Gimp-developer] change layout of mode menus?

2008-02-15 Thread Akkana Peck
Liam R E Quin writes:
 Seems to me that probably most people will use at most a couple of the
 layer modes in normal use, so maybe putting the top 7 on the menu and
 having a more modes submenu is a possibility.

Eek, please no! Often the best way to use layer modes is to go down
the list one by one, which would become even worse if you had to
click through a more submenu each time. Bad enough to have to
go to the bottom of the menu then wait for it to scroll.

Personally I'd like Bill's side-by-side mode menu, just because
it would be faster, and a shorter distance, to get to most entries.
But Sven does have a good point that it implies there's a connection
between each side-by-side pair of modes.

Bill wrote:
 I don't think I have to persuade anybody that this is less than
 ideal from a usability point of view.  The question is, can we do
 anything to make this better

I don't have a great solution, just a few specifics the gtk widget
doesn't do well that I wish the modes menus could handle better.
Like the fact that clicking on the button pops up the menu, but not
always with the current mode selected -- sometimes it's the mode
above the currently selected one, so I can't just arrow down once
and assume I'm on the next mode -- I have to look at the current
mode before I click, then choose the next one explicitly.

And I wish there was a faster way to select them by keyboard than
the current click on the button then use up or down arrow ... I
wish I could type ad and be on Addition right away.

Gimp-developer mailing list

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

2007-12-08 Thread Akkana Peck
William Skaggs writes:
 I find myself doing Edit-Stroke pretty often, and there are a few easy 
 that I think would make it signficantly better.
 1) The most important is that the dialog should not go away after the Stroke
 button is pushed.  It often takes several tries to get the settings right, and
 it is very annoying to have to bring the dialog back each time.  The gain in
 usability would easily be worth the cost of an extra button-click to close the
 dialog, in my opinion.

Certainly a full-size preview would be quite useful.  Like you, I
find that I usually Stroke several times trying to find the right
brush size (I usually stroke with the paintbrush tool, for its

It wouldn't have to require an extra click: make the dialog offer
a Preview button as well as OK. People who are sure they have
the right settings can click OK, everyone else can use Preview first.

Your other suggestions sound reasonable, but I seldom change the
line style so they're not burning issues to me.

Gimp-developer mailing list

Re: [Gimp-developer] redeye.c and gimp-2.4

2007-11-11 Thread Akkana Peck
Owen writes:
 Tried updating Robert Merkel and Benoit Drooghaag's redeye.c into gimp-2.4 
 but it failed.

You know about Filters-Enhance-Red eye removal, standard with
GIMP 2.4, I hope?

Gimp-developer mailing list

Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements

2007-11-04 Thread Akkana Peck
Sven Neumann writes:
 On Fri, 2007-11-02 at 23:55 +0100, Raphaël Quinet wrote:
  * jpeg plug-in
+ remove the prompt for EXIF orientation: it should always be done
 IMO the current solution of asking and allowing the user to skip this
 question is preferred. It requires a user decision once, but at least it

I like being asked. My Canon A540 quite often rotates when it
shouldn't (pointing the camera down, as I often do when shooting
flowers or lizards, confuses its orientation sensor). The current
dialog, with its thumbnail preview and its option of don't ask
me again, works very well (though as Sven says, it would
be nice to have an easier way of un-doing the don't ask).

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...

2007-10-28 Thread Akkana Peck
Guillermo Espertino writes:
 Tabs don't work for image manipulation because is frequent to compare 
 between two+ images or work with two views (one zoomed and the other at 
 100%) . If we use tabs we have only one image open at a time and that's 
 mostly a problem for pros.

Clearly it wouldn't be good to have tabs as the only way of using
multiple images. But there are lots of cases for which one tabbed
image window would be great. For instance, you're editing several
images from your camera. They're all the same size, you probably
aren't going to be doing much with layers or separate views, and
you're only going to be working with one at a time. A tabbed
interface would be ideal for that.

I'd love to see tabs as an option in image windows. As with Firefox,
you'd be able to choose Open in new window versus Open in new tab
in the same window. And of course you'd always have the New view
option regardless of whether you were using tabs.

Then people who only want one window (the people who ask for MDI,
or who don't have window managers with multiple desktops and have
trouble managing lots of windows) could put all their images in a
single tabbed window. Add menu integration and a way of docking the
toolbox and layers/paths/etc. dialogs, and you can get down to one
window, like the MDI fans want, without having to take away the nice
multiple-window multiple-view capability that current GIMP users enjoy.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] 2.3 Memory usage and leaks

2007-07-18 Thread Akkana Peck
Sven Neumann writes:
 What does gmemusage display? Does it only look at malloc'ed pages or
 does it also take code size into account?

I'm not sure. I think it's all of the above.

 On Fri, 2007-07-13 at 15:47 -0700, Akkana Peck wrote:
  I played around with gmemusage to get a feel for what was going
  on. GIMP 2.3 uses between 33.9 and 35.0 Mb on startup (no images
  loaded, and I don't know why it isn't always the same). For
  comparison, 2.2.13 uses about 13.9 Mb at startup, so it's increased
  by a factor of about 2.5 just for the base app, before images.
 That is most likely because your copy of gimp-2.3 has debugging symbols
 while your copy of gimp-2.2 doesn't. I wouldn't be surprised if gimp-2.3

That's a good point! But surprisingly, stripping the gimp-2.3 binary
and all the libraries in lib doesn't make much difference -- the
stripped 2.3 still takes 33M at startup.

Top showed:
gimp 2.356600  24m 10m 13.1
gimp 2.235984  20M9.8m 11.2

I haven't tested in valgrind yet, or with G_SLICE=always-malloc,
but I'll do some more experimenting (probably not for a few days ...
I have some projects coming due).

Gimp-developer mailing list

[Gimp-developer] 2.3 Memory usage and leaks

2007-07-13 Thread Akkana Peck
I just found my (wimpy laptop) machine running slowly after
processing a few (4) images with gimp from current svn (with several
scales, a crop and several saves) then closing all the image windows.
I ran a quick memory check and discovered that gimp was using 51Mb
despite not having any images open.

I played around with gmemusage to get a feel for what was going
on. GIMP 2.3 uses between 33.9 and 35.0 Mb on startup (no images
loaded, and I don't know why it isn't always the same). For
comparison, 2.2.13 uses about 13.9 Mb at startup, so it's increased
by a factor of about 2.5 just for the base app, before images.

Each time I load an image then close the image window without doing
anything, gimp grows by some variable amount, ranging from half a
Mb to 2Mb (perhaps related to the size of the image). If I do
operations on the image before closing it, these cause it to grow
more: doing a crop and a scale almost always makes it grow 2Mb
even with a relatively small image.

This seems like a memory leak (there's no usable history once an
image is closed, right? so basically it's back in the same state
it was before, except using more memory). Or is there useful
information that's being saved about each image? I know there's
one name and thumbnail added to the Recent Images list, but surely
that doesn't account for 2Mb. Nobody on #gimp knew much about it
when I asked, and there was some agreement that it sounded like
a leak.

However, I also see this ~2Mb growth in 2.2, so if it's a memory
leak, it's not a new one.

So my questions are:

- Is the growth that comes from loading an image, doing operations
  on it then closing the window expected? What is this memory being
  used for?

- Is anyone concerned about gimp's minimal profile having risen from
  14M to 35M?

If there's agreement that there's a problem I can file a bug and
maybe dig in more detail into where the memory's going, but I wanted
to ask here first.

Gimp-developer mailing list

Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Akkana Peck
peter sikking writes:
 But in between, as long as it is not finished, there is no role for  
 jpeg. Only one decompression at the beginning and a compression of the
 end result is defendable in high-end graphics.

I'm seeing an unspoken assumption in this thread that most photos
are edited in multiple sessions: read into gimp, do a few
operations, write to disk, read back in (perhaps hours or days
later), do a few more operations, write back out, repeat.

In my experience, it's much more common to read a jpeg in once and
do a lot of operations on it in one session, saving periodically.
There's no cumulative loss of quality: the intermediate saves are in
case of disaster like a power failure, not a way to quit gimp and
continue the editing process later.

But I think I remember Sven saying recently that Export would be able
to save without prompting each time, after the first time. (I guess
that means there will also be an Export As, in case you need to
change the filename?) So those of us who often work in JPEG could
use it just like we use Save now, and even bind ^S to it.

 If users get the hint
 that opening and saving the same jpeg again and again is a pain (also
 for the quality) and that either adopting a high-end GIMP file workflow
 or moving to another (mid-fi) app to work in their lossy jpeg way.

Another thing I'm unclear on in this thread: when I first heard the
idea of forcing Export instead of Save, the plan seemed to be that
Save would always save XCF, and anything else would require Export.
But now you seem to be telling us that the issue is lossiness, and
the point of Export is to make it more hassle to save to lossy formats,
to discourage use of those formats.  Does that imply that Save will
include PNG, TIFF and other non-lossy formats?

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] new rectangle tool specification

2007-07-04 Thread Akkana Peck
Sven Neumann writes:
[ ... ]
 The other aspect is not yet implemented. The spec suggests that when the
 mouse is over one of the corner or side handles, and one of the cursor
 keys is pressed, the rectangle shall be resized by one (shift: 15) image
 pixel in that direction and (new) the the canvas shall be scrolled in
 such a way that the position of the bounding rectangle under the sprite
 shall be constant.
 I don't think that scrolling the canvas is a good idea.

If the canvas isn't scrolled, the spec should probably mention what
happens on the next keypress. Suppose I have the mouse cursor over a
side handle and I press right-arrow. The side handle moves right by
one image pixel. Now the side handle is no longer under the mouse.
If I press right-arrow again, I hope it would move another pixel,
since arrow keys aren't very useful if you can only move one step.

But that requires that the tool go into keyboard navigation mode
where the tool remembers that one handle is active and is subject to
being moved by arrow keys even if the mouse is no longer over that
handle.  How will the user see that it's in that mode?  I'd suggest
keeping the handle outline bold with the 2-pixel border described in
the spec, even after it moves out from under the mouse cursor.
But if the mouse moves (more than some threshold?) then un-highlight
the active handle and go back to normal mouse-activated mode.

Of course you could warp the mouse cursor to follow the handle,
but I doubt anyone wants to do that, especially in an app used with
graphics tablets.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] JPEG plug in : added a default settings record and debug

2007-06-30 Thread Akkana Peck
guepe writes:
 The Gimp JPEG plug in does not allow to save defaults settings from
 session to session. It does exists for the PNG one (see bug #63610).
 I decided yesterday to write the same thing for jpeg, I submit the
 source code (mainly inspired from the PNG implementation).

That should be a popular patch! It's something that lots of people
have asked for.

 I sent a first mail with the code source attached, but it has been
 blocked by size.Source code is at :

The best way to submit patches is usually to attach them to a
bugzilla bug. Submitting them in a mailing list makes it really easy
for them to get forgotten before anyone has time to review them.

In bugzilla, the main bug on this seems to be
though there's a very similar bug that depends on it,
Probably one of those would be the best place to attach your patch.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] Webdesign is wrong

2007-06-25 Thread Akkana Peck
David Marrs writes:
 4) Open new canvas. PS automatically populates the canvas dimensions with 
 of the paste buffer so this operation isn't as cumbersome as it would be in 
 Gimp, but really it wouldn't be required at all if PS allowed you to edit an 
 image during the next stage.

I might have misunderstood this step (I definitely don't follow the
comment about PS not letting you edit -- maybe that's a PS issue)
but it sounds like if you did a Paste as New in gimp, you wouldn't
need to create a new canvas or figure out any dimensions.

Gimp-developer mailing list

Re: [Gimp-developer] What happened to FFT forward and backward plugins?

2007-06-08 Thread Akkana Peck
Mark Lowry writes:
 I had 2.2.13 on my PC and it didn't have
 FiltersGenericFFT Forward or FFT Backward.  I have
 2.2.14 on my laptop and those filters are there.  So I
 just installed 2.2.15 on my PC and those filters
 aren't showing up.  What gives?

Maybe you installed the Fourier plug-in at some point on your laptop?

(I found that by googling on gimp fft -- it was the first hit.)

Gimp-developer mailing list

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools

2007-03-20 Thread Akkana Peck
  Come on, that is simply a rude accusation.
 Is it rude? It seems perfectly reasonable and polite to me. Interestingly  
 Sven seems to find this highly offensive as well. May be you think taking  
 offense somehow negates the criticism. It seems you both are not too good  
 a taking what you give out to others and quick to take offence where it  
 was not even intended.

One key aspect is Joao's comment that outsiders preceive the project
as rude -- and he gave several very recent examples of why this
perception exists.

Even if an original question seems rude or stupid, answering it in a
rude or brusque manner creates a perception that GIMP is not a
friendly project for outsiders.

Maybe that's the intent -- to set up a gauntlet that weeds out any
potential participants who might be lazy or thin skinned. If so, no
problem. But if you actually want lots of new participants, then how
other people perceive the project matters.

Being perceived as friendly takes some effort -- and sometimes it
means trying to seem friendly even when you don't feel that way, and
even when you feel justified in being abrupt because the question
was lazy.

 Simon , who I cant remember as being rude or off-hand to anyone, seems  
 confused yet polite, not offended.

Yes, it's ironic to see Simon targeted in this discussion -- he is
not one of the main offenders here and is consistently friendly and
helpful in general.

Joao S. O. Bueno Calligaris writes:
 Simon, where does that forbid one to add words 
 like thanks, please, would and etc... to even a short answer, 
 like a FAQ URL???

Is there a FAQ URL? There's nothing linked from the top level of There is a FAQ page on the wiki, but it begins with a
disclaimer that it's out of date and people should go to the GIMP
manual instead (which doesn't answer most of the FAQ questions).
I wish the person who added that out-of-date notice had actually
mentioned *which* answers were out of date, which would make it a
lot easier for volunteers to find and update them.

And the FAQ doesn't have anything on the language(s) used to write
GIMP. I know it sounds like a stupid question -- that was my
reaction too -- but it's not the first time I've seen it asked on
the mailing lists, so maybe it belongs in the FAQ after all,
along with how to take a quick look at GIMP code (viewcvs)
without downloading the whole tarball.

Except I'm hesitant to run off and register for the wiki so that
I can add it, given that it's not linked from the main GIMP site,
no one refers to it and the page itself discourages anyone from
using it.

If there's no easy-to-find FAQ document, then is it fair to get mad
at people for asking FAQs?

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] SoC project ideas

2007-03-06 Thread Akkana Peck
Sven Neumann writes:
 Create an SDI manager widget
   Do we really want to ask someone to waste his/her time with this? It 
   is in my opinion not implementable in a sane way and we would likely
   not accept the results then. If this is supposed to be kept on the
   list then we need to agree first that we really want such a thing.

Another possible approach which might be more generally useful is
tabbed image windows (suggested in bug 121087), combined with moving
the toolbox menus into the image window. Then people could dock the
toolbox and do everything in one window if they so chose, while
others could keep the current separate-windows model.

 Additional file format plug-ins 
   Shouldn't this perhaps be titled Improve MNG support?

There are a few other file format plug-ins I've seen discussed
here recently, such as GeoTIFF and improved PSD support.

 On-canvas text editing 
   Nice, but pretty much depends on the port of the display code to
   Cairo. Perhaps concentrate more on rich text support instead of
   focusing on the on-canvas editing?

Rich text support would be a very useful and fun SOC project.

It might require architectural agreement on how the rich text would
be stored in the XCF (which might not be backward compatible).
Is that a problem? Or is there already a model for that?

 Search-based menu browser
   Nice and probably even reasonably well specified. The student should
   perhaps do some usability work on this him/herself (with the help
   of an expert).

Peter says this sounds like flagging usability defeat and I
understand why he says that, but I don't agree. Consider it a type
of online documentation. Realistically, any program that offers as
many different unconnected functions as GIMP does cannot organize
them in a way that will be immediately intuitive to everyone,
especially someone who doesn't understand conceptually what the
functions do. Consider the person who's following an online
tutorial. The tutorial says Step 12: run HSV Noise. The user
may not understand what HSV noise is or why it's needed at this
step; they just need to find something matching the name HSV Noise.

 Redesign and reimplementation of Save and Export in GIMP. 
   We really need to do this, finally.

When I saw the header I was hoping this covered things like
remembering settings from the various save plug-ins (like, always
show JPEG preview, always save exif, never save thumbnail).
Turns out that's not covered -- but it would make a nice SOC project
that would be very widely useful.

 Meta-data plug-in 
   I would love to see the metadata plug-in finished and the framework
   used from other file plug-ins. This is crucial for 2.6. Probably up to
  Raphael to decide if making it a SoC project can help to make this happen.

I think lots of people would like to see this, but everyone is
afraid to touch it because the comments in the bug make it clear
that Raphael owns the problem and it's presented as a big
complicated project. It would be great to see it separated into
smaller pieces so other people could attack it.

If a general metadata plug-in is too ambitious, how about a
straightforward EXIF and Comment editor? Then if the more general
metadata thing ever gets finished, it could replace the simpler one.
There's an old exif plug-in on the registry (written by Bill)
that might offer a start, though it doesn't currently allow for
editing or viewing.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] Crop+Scale (was Save As JPG Integrated)

2007-02-08 Thread Akkana Peck
Sven Neumann writes:
 If you had read the specification (and I expect all of you to have done
 that), you would know that the current state of the rectangle tool
 options panel is far from final. 

I knew it wasn't final. I did wonder what the current buttons were for.

The specification you're referring to is the one Peter posted to
this list in December? In other words,
(The image attachment didn't make it to the archives, but I saved
the message and it's not that different from the current aspect
ratio, except that it has portrait and landscape buttons to the
right of the text field instead of the mysterious Fix.)

I'm confused about one thing in the spec: it says
| From all three tool option panels, remove all the Fix buttons,
| The line with the Aspect fields, and the three buttons below it.

Just to be clear, the line with the Aspect fields isn't really
removed, just changed to look like Peter's sketch, right? So the
text field stays, a Use ratio checkbox is added above it, and the
Fix to its right are replaced with the portrait/landscape icons.

I'd be happy to update the tool options to be more like the spec,
if you're looking for a volunteer and it wouldn't step on any toes.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] Save As JPG Integrated (mockup)

2007-02-03 Thread Akkana Peck
Thorsten Wilms writes:
 I found toggling between  
 original/preview in the same view to be superior if  
 you want to spot JPG artifacts.

Me too. The new setup where the preview is a layer in the image
dialog (I just updated and saw it) is wonderful. I'd been struggling
with focus/raise issues with the old separate-window setup (click on
the dialog and it would raise the original image window, hiding the
preview window, and even when that didn't happen I was always
confusing the two similar looking image windows); using a new layer
is a great solution and makes it so much easier to see the effect of
the quality settings.

I'll add another vote for hiding the Save as dialog when bringing up
the JPEG dialog.  I often go to the wrong one of the two dialogs
after changing desktops or shuffling windows around to see the
preview better. Partly that's because they always pop up widely
separated on the screen, rather than placing the second dialog on
top of the first (they seem to trigger different window manager
placement rules).  And the buttons on the dialogs are a bit
confusing: they both show active Cancel buttons, but Cancel
on the Save As dialog is a no-op.

I wish there were a way around needing two dialogs (needing to click
Save two different times in order to save). Seems like there must be
a way around that, but I can't think of one. Putting jpeg options
and dialog-like buttons into the image window doesn't seem like a
better solution: you still need to click just as many times, and it
sounds jarring for the familiar image window to temporarily change
its UI and act like a dialog.

peter sikking writes:
 because the task is modal by nature, the UI
 UI has to reflect that with dialogness. It is simply a UI
 law of nature.

Is that an argument for making the two dialogs window modal?
They aren't now -- I can go back to the image window and draw on
it, or whatever, while the dialogs are up.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] Meaning of delay in screenshot plugin

2007-02-01 Thread Akkana Peck
peter sikking writes:
 I got the fling that ksnapshot manages to take a snapshot of
 the window + menu. There is where I got the idea. But reading
 the documentation again, they do not 100% promise this.

I should have tried ksnapshot before!  It does get the menus --
even on Edgy where GIMP's snapsnot just gets garbage.
If you have the mouse over only a menu, ksnapshot will even
give you just the menu without the window containing it.

ksnapshot solves the delay problem in a nice clean way:
they have only one (pre-selection) delay, but their window selection
is Window under cursor -- you don't need to click to select
the window. That solves everything without requiring two delays.
It's a nice solution!

(Now off to poke around X and think about Sven's fabulous super-
layered-screenshot idea.)

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] Meaning of delay in screenshot plugin

2007-01-31 Thread Akkana Peck
peter sikking writes:
  Peter, I have to ask: how much have you actually used GIMP for
  screenshots? Have you done a lot windows cut from full-screen
  screenshots? Or talked to users who do?
 I am an interaction architect, I have to take a decision what is
 the best solution for 1 million users. We spend time evaluating
 this feature systematically. We especially focussed on your
 use case. But we saw the cost in UI complexity to put in the
 second delay. This complexity slows down 99% of the users,

Not being an interaction architect, I'm still not understanding.
How did you arrive at the 99% number? Is that the percentage of
users who would be slowed down by seeing both delay options?
Or by the previous behavior of having a delay only after selection?
What is the corresponding percentage of users who are slowed down by
having only a before-selection delay?  Are these numbers based on
usability testing, or user interviews, or analysis of bugs or public
comments, or what?

I'm hoping that, this being an open source project, the methodology
involved in this interaction analysis is public and available for
everone to see and understand and learn from.

[pre- vs. post- selection delay]
 I estimate the chance that one is not taking a screenshot of GIMP
 itself as higher than 50%. So you need time to get GIMP out
 of the way.

To get the screenshot dialog out of the way, you mean?
Is it really that common to screenshoot a single window which is
so large that there isn't room for both it and the screenshot dialog
on the screen at the same time?

To the list: does anyone here actually uses the delay for that purpose?
The people who have asked for before-screenshot delay mostly seem to
want time to switch desktops (a valid reason but surely not a 99% case).

 In 'snap window' mode the shot shall be taken:
 a) on the first mouse-down after the timer (can be zero) has expired;
 b) immediately, when a non-zero timer expires AND a mouse-button
 (left, right [pop-up menu], even middle?) is being held down.

That takes care of menus, but there transient effects which don't
involve a mouse button down. For gimp, examples include the cursor
outline of a brush, or the line you get pressing shift in a drawing
tool. That's admittedly an uncommon case, but how about the very
common case of hover effects in a browser?

I also wonder about discoverability: Sometimes I have to click on
the window after the delay, but sometimes I don't. Will people
figure out that having a mouse button already pressed is what
makes the difference?

Steve Stavropoulos' interface, with the two clearly explained
delays, seems so much easier to understand than trying to intuit
a mouse-already-down behavior.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] Meaning of delay in screenshot plugin

2007-01-30 Thread Akkana Peck
Alex Pounds writes:
 On Tue, Jan 30, 2007 at 08:22:11PM +0100, Sven Neumann wrote:
  Any particular reason why you didn't use the screenshot feature of your
  desktop for this? Just asking. 
 Not everybody uses a desktop that has a screenshot feature built in. I
 don't, and whenever I want a screenshot I use the Gimp plugin. I would be
 very disappointed to see it removed. 

Same here. I have set up a desktop function that does a screenshot
via import (from image magick); but that doesn't allow me controls
like delays, and it saves to a file which I then have to open in
gimp as a separate step (and remember to delete later). I use it
for quickie show someone on bugzilla or IRC what I'm seeing snaps
but not for the important ones.

For what it's worth, every time I see the question How do I make
a screenshot? posed on a beginner/intermediate Linux list, the 
answer always ends up being GIMP. It's still the best method
that's not dependent on users running specific versions of
specific desktops.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] changes in script-fu in 2.3.14

2007-01-30 Thread Akkana Peck
Sven Neumann writes:
 On Tue, 2007-01-30 at 08:22 +0100, Sven Neumann wrote:
  I don't think that the NEWS file is the right place for this. Someone
  should set up a detailed description of the changes with instructions on
  how to fix scripts that stop working after the update. We should then
  refer to this document from the 2.3 release notes (and of course also
  from the 2.4 release notes when they are written).
 Any volunteer for this?

Doesn't that require someone with a good knowledge of what all the
changes are?

If someone can make a quick comprehensive list, I'd be happy
to help with getting it into a more readable form, if that's the
issue. I don't know enough about the changes to make the list myself:
I know what I've done to convert a few small scripts, but we need
someone with more general knowledge than that.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] 2.4 showstoppers

2006-12-20 Thread Akkana Peck
Sven Neumann writes:
 I don't think that comparable functionality is a goal of the new Print
 plug-in. People can always install the gutenprint plug-in if they need
 this functionality. 

Robert L Krawitz writes:
 Whatever one thinks of all the color adjustments and the
 Gimp-Print/Gutenprint UI in general, the live preview and margin/page
 adjustments always attract comment if something breaks about them...

The live preview is essential for non-geeky people and visually
oriented people (artist types), who aren't going to try to
go from text like .8 inches, Reverse Landscape to visualizing
what will actually be printed.

I might be biased. Gimp-print, and particularly its live preview,
was the key that enabled me to switch to Linux full-time back in the
day.  Before that I'd been fighting with Photoshop LE, which had an
absolutely horrible print UI: you had to click a secret unlabelled
area in the status bar to pop up a preview window, which consisted
of a white rectangle with an X over the part that would be
printed.  Gimp-print's low-res preview showing the actual image may
not have been perfect, but it was a huge improvement in usability
over anything I'd found on Windows.

Setting unequal margins is an intermediate case. That's really
useful for one task a lot of non-geeky users might like to do:
printing holiday cards. But maybe that one's less important since
there's a workaround, even if it's more hassle (position the image
on a white canvas 2.x times as large).

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] 2.4 showstoppers

2006-12-19 Thread Akkana Peck
Sven Neumann writes:
 thanks for looking at the plug-in. It would help a lot if we could split
 your list into problems of the Print plug-in and problems of the
 GtkPrint API. The latter would have to be reported against GTK+.

I've filed a gimp bug (#387604) on the unit factor problems (I
suspect the dialog disappearing on Print Preview is the same
problem; at least it's not easily separable from it right now).

I'm not sure which of the other problems is GtkPrint vs. GIMP,
because I'm not familiar with what GtkPrint does. Two bugs that
seem worth filing:

- Not reading the system paper size (I'm guessing this is gtkprint)
- Two different functions named Page Setup (I'm guessing this is GIMP)

Do my guesses sound right?

And a few RFEs which would be needed to get the print dialog to
functionality comparable to the existing gimp-print plug-in.
I don't know whether these belong to gtkprint or gimp:

- No way to adjust margins
- Page Setup should be in the Layout tab, not a separate dialog
- No live preview

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] 2.4 showstoppers

2006-12-18 Thread Akkana Peck
Sven Neumann writes:
That brings up another showstopper for 2.4 that is missing from the list
I posted earlier. We need to check if the new print plug-in is ready for
release. Since I don't use GTK+ 2.10 yet, I didn't get a chance to have
a look at it yet.
[ ... ]
  It should at least do the basic things right. In other words, print a
  single image, allowing the user to specify the size and location on
  paper. Should probably default to the original size (determined by the
  image resolution) if that fits to the printable area. Otherwise it
  should scale the image down while preserving the aspect ratio.
  For this plug-in I think we should focus on keeping it simple. Enough to
  fulfill basic printing needs but still usable without reading a manual.
  People who need more control can always install the gutenprint plug-in. 
 Has anyone done this evaluation? If not, can someone please volunteer to
 do it? We need to find out if we can we ship the plug-in as is or if
 there are issues that need to be addressed before 2.4.

I just upgraded to a distro that has gtk 2.10, so I can do
the evaluation -- though for my own use I'm fairly happy with

I just tried the print plug-in in current CVS. This is the first time
I've actually seen it, and I'm happy to see that there's a gnomeprint
dialog now that lets me set printer parameters. But I found quite a
few problems, and ultimately wasn't able to print anything with it:

- Bug: the Layout tab comes up with a unit of Inches, but Width and
  Height which are the pixel dimensions of the image. I hate to
  think what it would do if I let it print at 1160 inches wide.

- The Layout tab is really difficult to use compared to gimp-print,
  because it has no live preview. I have to click on the Page Setup
  button (why isn't that right in the Layout tab?) then try to guess
  what it means by Portrait, Reverse Landscape, etc. and what it
  will do for margins (does it always center, or what?)

- Minor Bug: the Page Setup dialog came up with the wrong paper size
  (A4 vs. my system default of Letter).

- UI issue: there's a Page Setup tab, plus a Page Setup button in
  the Layout tab which has a completely different function.
  Shouldn't one of these be renamed? (Moving the Page Setup button/
  dialog options into the Layout tab and eliminating the dialog
  would solve this.)

- There doesn't seem to be any way to position an image on the page,
  so this dialog doesn't replace gimp-print for functions like
  printing out my holiday cards, where I have to print to the
  lower half of a page which will then be folded over.

- When I try to change the Width in inches to 4, as soon as I
  leave the Width field it reverts to the old value of pixel width.
  So I can't actually try printing anything to check the quality.

- When I click Print Preview, the dialog disappears and I get a
  GIMP Message dialog with a nice clear error message:
Procedure 'gimp-image-set-unit' has been called with value
'pixels' for argument 'unit' (#2, type GimpUnit).
This value is out of range.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] default setup for 2.4 comments

2006-12-13 Thread Akkana Peck
Sven Neumann writes:
 On Tue, 2006-12-12 at 15:18 -0500, Kevin Cozens wrote:
  I prefer to have these showing in the toolbox. When I lost them a some time 
  ago after a cvs up, the first thing I did was find out where they went and 
  to get them back.
 You could at least have tried to live without them for a while before
 judging about this change. That's one of the main problems with the GIMP
 user interface. People are afraid of trying new things and miss what
 they have learnt to use. So, the fact that you immidiately renabled
 these widgets only show us that you are reluctant to changes. It doesn't

I'm not Kevin, but I had the same reaction he did. In my defense
(and maybe Kevin's), when the toolbox selectors disappeared, the
new dialogs didn't automatically make themselves visible, so it
just looked like a bug that they were suddenly gone, and getting
back my color selector was my first priority. A new user wouldn't
have that problem.

But Sven is right (even though he's talking to Kevin) that some of
us didn't give the new layout a fair chance.  So I've been doing
that for the past couple days, and it actually works fine. I like
not needing the popup any more, and for most operations it doesn't
require any more clicks than the old layout.

There are still two things I miss. Neither of these will stop me
from using the new setup, but I wonder if they might cause a problem
to non-geeky users:

1. Being able to drag from the foreground or background swatch
into the image. Sometimes I use the keybindings (ctrl-, and ctrl-.)
but other times it seems more natural to drag the color, and if
the swatches aren't exposed (because they're hidden in a tab),
it would take two extra clicks to drag them (two clicks assuming
that I need the layers dialog visible most of the time, so I need
to switch back).

2. The sliders for RGB. I can do HSV adjustments in the big color
rectangle, but if I want to adjust RGB values (for instance, to
ensure that I'm getting pure red) I have to use the HTML field or
click the R, G and B buttons in sequence. I can't just glance at the
three sliders like with the old dialog.

Beginning GIMP: From Novice to Professional:
Gimp-developer mailing list

Re: [Gimp-developer] panning

2006-07-06 Thread Akkana Peck
Joao S. O. Bueno Calligaris writes:
 I am a heavy user of the push-move feature, and I know of other 
 people who are.
 There are 105 keys on the keyboard - and both features are a good 
 thing to have with push functionality.  I do not care if the move 
 push is changed to any other key, and space be left to pan. But I 
 care about loosing the current feature.

I also use this feature a lot. If there's a conflict with the
proposed panner, I'd love to see the key made configurable, because
then it would be at least somewhat discoverable (to those who go
through the Preferences window carefully). But in truth I don't care
very much which key activates the temporary move tool; I just hope
some key will, since the feature is so very useful.

Gimp-developer mailing list

Re: [Gimp-developer] menu cluttage

2006-07-05 Thread Akkana Peck
Sven Neumann writes:
 And so far I don't see anyone complaining about my proposal to not
 install any Python scripts at all with GIMP 2.4.

Not installing scripts that are there strictly as example code
makes sense. Would they stay in CVS head, so it would be easy
for people learning gimp-python to find them?

What about the few python scripts that perform functions that aren't
otherwise available? Even if they're not perfect, some of them
seem useful. For instance, py-slice can be very handy for some
people (if they don't have gimp-perl and perlotine).  Foggify is a
bit different from anything else that's installed by default, isn't
it? And it seems to work okay even if the default color makes me
wonder where the author lives (orange reflections from low-pressure
sodium lighting?)

Gimp-developer mailing list

Re: [Gimp-developer] feature request

2006-07-04 Thread Akkana Peck
Tim Jedlicka writes:
 On 7/2/06, Marco Ciampa [EMAIL PROTECTED] wrote:
 Why not to bring all the GIMP windows up over all the others windows when
 I clic on to one of the many GIMP windows?
 While in the image window - try a Shift-Tab (it may just be my window
 manager (gnome/gdm)), but this works well for me.

Doesn't work here in fvwm. It makes the Toolbox and dialogs
disappear; then another shift-tab brings them back, on top of
other windows. In neither case does it affect the stacking order
of any gimp image windows.

I wouldn't want to see a click on any window bring all the others
forward. That would be really annoying, since there are many reasons
for clicking in a window and most of them don't involve any of the
other windows that might be open.

But I agree it would be quite useful to have some way of bringing
all gimp windows to the front, ideally via a menu item (which could
then be bound to a keystroke). There are definitely times when I
would use and appreciate that.  (As a workaround, what I do is tell
my windowmanager to move whatever window is hiding gimp down to the
bottom of the stack.  I'm not sure all windowmanagers offer a way to
do that, though.)

If this gimp function was implemented, it would have to loop over
the image windows and bring each one forward ... in what order?
Order by last access time? Does gimp even keep information about
the last time at which each currently open image window was accessed?
I suppose it isn't that critical as long as the one most recently
accessed image window ends up on top along with the Toolbox and

Check out my book, Beginning GIMP: From Novice to Professional.
Now shipping! For more information:
Gimp-developer mailing list

Re: [Gimp-developer] new default icon theme proposal

2006-06-15 Thread Akkana Peck
Jakub Steiner writes:
 You can preview the looks of the new GIMP icon set here:

Nice icons! I have one comment about the SIOX icon in the light set.

In current CVS, I find that the SIOX icon looks very different from
the rest. It constantly draws my eye to it and makes me think
that it is the selected icon even when it isn't, because it's an
icon on a darker square background which makes it look a bit like
a pushed in button.  I was hoping this this was only temporary and
would change in the new icon set, but it looks like the SIOX icon
hasn't changed as much as the others. 

Would it be possible to make its background lighter, or even get rid
of the background, to make its style better match the other buttons?

Gimp-developer mailing list

Re: [Gimp-developer] new default icon theme proposal

2006-06-15 Thread Akkana Peck
Jakub Steiner writes:
 Thanks for the constructive feedback Akkana. It indeed is one of the few
 icons with solid background. I tried to convey the fg/bg separation
 message better this time around. Does that work for you?

Much better! It still stands out a little, especially if you put
it into a stock toolbox that doesn't have any of the other
icons-with-background enabled (so it's the only icon whose outline
is a square box instead of an irregular shape). But the important
thing is that it no longer looks selected, and it doesn't draw the
eye away from the other tools so much now.

Gimp-developer mailing list

Re: [Gimp-developer] Compiling gimp under debian with gimp-print support

2006-04-16 Thread Akkana Peck
Frédéric writes:
 I successfully compiled gimp-cvs under my debian testing, but without 
 gimp-print support.
 What do I need to install to get it ? I can't find any gimp-print-dev or so 

When you're searching, be sure you use a search that would catch
both gimp-print and gimpprint, e.g. aptitude search gimp | grep print.

But it's likely that they've switched to gutenprint (new name, same
project), and although there's a libgutenprint-dev package (at least
here in Ubuntu), GIMP's configure script is only set up to look for
older gimp-print headers, not the newer gutenprint ones.

My understanding is that the gutenprint gimp plug-in is now expected
to come from gutenprint, rather than from gimp. (Maybe someone else
can clarify that.)

In any case, it does work to build gutenprint from source
( ... and yes, the page still
says Gimp-Print, but if you click on Download you'll find the
gutenprint releases. It's all very confusing). Make sure that the
gimp2 print plugin is enabled (I believe it is by default,
at least if you have the gimp dev headers installed). Then the
plugin will be built in the gutenprint source tree for use with
your CVS gimp.

Gimp-developer mailing list

Re: [Gimp-developer] Re: Comments on gimp's interface

2006-04-07 Thread Akkana Peck
Pär Forsling writes:
 Akkana Peck [EMAIL PROTECTED] wrote:
(about problems Tab causes because the focus ends up in the wrong
window, and wanting a way to disable Tab).

 Have you posted a bug report to bugzilla about the wrong focus
 behaviour? Otherwise I'll do it.

I haven't, because the focus behavior is mostly normal window
manager behavior. It would be nice if GIMP could set focus back
to the image window after Tab brings back other windows, but that
seems fairly difficult to do in gtk. I wasn't confident such a bug
would be accepted.

And since I never actually want the Tab behavior anyway, and Tab
is so easy to hit by accident, I'd still like a way to disable it.
Grabbing the focus back would help in that correcting an accidental
Tab would only take one keystroke instead of a keystroke-plus-mouse-
out-plus-mouse-in; but I'd rather not have to correct it at all.

Gimp-developer mailing list

Re: [Gimp-developer] Comments on gimp's interface

2006-04-03 Thread Akkana Peck
Sven Neumann writes:
 And how do you reenable a popup that you have asked to suppress? I
 think that we should try to avoid popups but simply not showing them
 is not an option. If we can get away without showing the dialog, why
 do we show it at all then?

In the case of the warning popups when saving, why show them
at all? Of course it needs to flatten layers when saving to JPEG;
why not just do it without asking me every time? It's not like
I have an option to save without flattening; all I can do is
press OK.

In the case of converting to indexed to save as gif, there's
some point to it because the user might not realize there's such
a severe loss of quality about to happen; but it's still not
important enough to warrant a whole extra dialog to which the
only options are OK/Cancel. Just put it in the normal GIF save
dialog, as a label that says Image will be converted to Indexed
mode before saving if the image isn't already indexed.

A similar case was the warning I saw sometimes when a layer mask was
selected. I never quite figured out the point of that warning since
it seemed to save the image correctly anyway. But that dialog seems
to be gone now in CVS HEAD.

  #4 : if you maximize your artwork, the panels are over it, it makes
  the extreme areas of your work inaccessible without moving your
  panels, or going fullscreen.
 Hit Tab and the panels are out of your way.

Is there a way to disable this? It gets in my way, because I hit it
fairly often by accident (probably when I'm trying to hit 1 to make
the image full-size), and it's several steps to undo it: in gimp 2.3
a single tab brings all the windows back (much better than gimp 2.2
where it took several tabs) but in the windowmanagers I use, the
focus now moves to one of the restored windows so it's no longer in
the image window where it was, and I have to move the mouse out of
the window and back in. I've looked for places to disable it, but 
I don't see anything about the tab key in the Keyboard Shortcuts
window or in menurc where other key bindings are controlled.

Gimp-developer mailing list

Re: [Gimp-developer] Re: Comments on gimp's interface

2006-04-03 Thread Akkana Peck
I wrote:
 In the case of the warning popups when saving, why show them
 at all? Of course it needs to flatten layers when saving to JPEG;
 why not just do it without asking me every time? It's not like
 I have an option to save without flattening; all I can do is
 press OK.

I posted hastily: this dialog does have more than one option. And
the other dialog, that I said no longer existed in CVS HEAD, is
still there (I don't know why it didn't come up for me earlier).
Here's the sequence if a layer mask is selected:

First, a dialog that says You are about to save a layer mask as
JPEG. This will not save the visible layers. So what WILL it save?
There's no way of telling from the text in the dialog.
Options are:  [Cancel]  [Confirm], so Confirming is really
the only choice.

If you Confirm this, then at least for jpeg, you get the
flatten dialog: JPEG can't handle transparency, Flatten?
The choices here are:  [Ignore] [Cancel] [Export]
Export is almost always the right answer, since that saves the
image as you're looking at it in the image window -- even if you
just dismissed that scary layer mask dialog that said it wouldn't
save the visible layers.

It turns out that what [Ignore] means here is Save the current
layer instead of the whole flattened image. And in that case,
if you went through the layer mask dialog earlier, what will be
saved is the layer mask, otherwise you'll get the layer (with no
layer mask applied).

If you wanted to save a layer or layer mask in a format that
doesn't call up the Flatten dialog (say, as XCF), you're out of luck.
The only option is to paste it as a new image and save that.

This would all be so much clearer if Save As just saved the current
image (the whole thing, flattening as necessary without pestering
the user about it). For people who want to save just one layer
(or mask), offer a separate menu item for that, perhaps in the
context menu of the layers dialog, as well as in either the File
or Layers main menubar.

Right now Save As is overloaded to do two fairly different
operations -- but only if you're saving to a format that doesn't
allow layers. Why not separate those two operations as separate
menu items, and have it work the same regardless of format?

Bug seems to
be the best discussion of these export dialogs, but it doesn't
really address the issues I mentioned (I should probably add
a comment).

As long as we're talking about Save issues, bug 75459 is another
one worth looking at (both referenced from the bug 119545 that
GSR mentioned).

Gimp-developer mailing list

Re: [Gimp-developer] Bring Back the Keyboard!

2006-02-14 Thread Akkana Peck
Joao S. O. Bueno Calligaris writes:
 Unless, of course, the filename is in the ~/.gimp-2.x dir and you try 
 to getthere by start typing .
 I am serious about this: I _lost_ almost 20 minutes in a 3 hour 
 workshop trying to get people to open files in ~/.gimp-2.x - and 

It really is fairly tricky with the new file selector to explain to
people how to get to files in ~/.gimp (for instance, to save or
manage custom brushes, gradients etc.)

I know this isn't the place to flame about the gtk file selector and
save-as dialogs ...  but given that GIMP does use the new dialogs
now, and that there are sometimes valid reasons to need to open or
save images inside the GIMP profile, has there been any thought on
adding a gimp-specific button in GIMP's version of the dialogs which
would take the user directly to the user's GIMP profile?
That is possible with the current dialogs, isn't it?

It would make life so much easier for newbies who aren't entirely
clear on the concept of a file system (and believe me, there are a
lot of people interested in editing images who have no idea whether
they have a home directory or how to manage subfolders, let alone
hidden directories), as well as for the people who are trying to
teach them how to use gimp.

The advantage over a bookmark (besides not needing to figure out how to
navigate there the first time) is that most people don't edit images
inside their gimp profiles often enough to make it worth adding a
bookmark that will then show up in every other gtk app they use.

Gimp-developer mailing list

Re: [Gimp-developer] Designing a Better Font Selection Widget for use in Open Source Software

2005-09-27 Thread Akkana Peck
Nice proposal. A lot of apps could benefit from a good shared font
selector -- it's not just an issue of one app, as you point out.

I love the idea of font groupings. I don't mind editing an XML file,
but I'm sure it wouldn't take much to whip up an app to help people
customize their downloaded fonts, compared with the rest of the
work involved in the proposal.

Tooltips over menus can be really annoying, because while they're
showing more information about one entry they're preventing you from
scanning all the other entries. You can move the mouse outside the
menu, but it's a shame to have to mouse in to scroll, then quickly
mouse out before the tooltip blocks the list you're trying to read.
Please consider making that part optional, or skipping it.

One more UI issue you don't address: the length of the font list
can be a problem, especially if you have a lot of fonts installed.

The current GIMP font list (and your proposal looks similar) pops up
as a combobox that shows, on my system, 9 fonts at a time. Exploring
the whole list through this small window takes a long time and a lot
of clicking.

Sometimes I really miss having a font selector dialog which I could
resize to show a long list, so that I could scan through more quickly
without needing to scroll so many times. 

Gimp-developer mailing list

[Gimp-developer] Using GIMP for Paper Prototyping the Colors Menu

2005-08-27 Thread Akkana Peck
Anyone pulling CVS has probably noticed that most of GIMP's
color-related functions have been moved into a new toplevel Colors
menu (as discussed in bug 116145).

There's some concern that the menu is a bit long, or could be
organized better. Sven has been enthused about paper prototyping
lately (see discussion in his blog entry) -- that's where you write
things down on slips of paper and shuffle them around to come up
with the order that seems most intuitive. The problem is, you need
to get everybody together in a room for that, which is hard with a
worldwide development community.

Apparently someone (in gnome?) is working on some sort of
card-sorting app to help with distributed paper prototyping. But it
occurred to me (based on an offhand comment I read on slashdot, of
all places) that GIMP itself could be a pretty good paper
prototyping system.  After all, you can have lots of text layers and
drag them around with the move tool, and there's even a way to save
your work when you're done.

So I wrote a little quickie paper prototyping script-fu. It's at
Drop it into your ~/.gimp-?.?/scripts directory and Refresh Scripts.
It registers under Xtns-Script-fu-Misc.

Fill the textarea with a list of your paper prototyping terms, one
per line, and it will make an image where each phrase is a text
layer you can drag around.

Anyone concerned with the Colors menu, please try this and drag
stuff around and see if you find groupings you like better than the
current ones.

For the current Colors menu, the strings to paste into the
paperproto dialog are (copy and paste the whole block):

Image Mode
Color Balance...
Value Invert
Colorcube Analysis...
Adjust FG-BG
Alien Map 2...
Color Exchange...
Color Range Mapping...
Colormap Rotation...
Gradient Map
Palette Map
Sample Colorize...
Border Average...
Channel Mixer...
Color to Alpha...
Filter Pack...
Max RGB...
Smooth Palette...
Draw HSV Graph...

Happy prototyping!

Gimp-developer mailing list

Re: [Gimp-developer] GIMP print dialog issues

2005-08-15 Thread Akkana Peck
michael chang writes:
 Some who are prompted for auto-flattening-export think it
 will perminantly flatten their image, and look for a work around.

In CVS GIMP, the export dialog does say, The export conversion
won't modify your original image, so at least users shouldn't
be worried about that (if they read the dialog).

But I'm not sure why the dialog exists in the first place. Is there
any reason the user needs to be prompted for this? It doesn't modify
the current image, it's just a temporary thing for printing.
Clicking Ignore seems to do the same thing (at least on Linux and
current CVS) as clicking Export, so the user doesn't have any useful
choice to make here, just a confusion between two apparently
identical choices (or Cancel).  Why not just do the conversion
without bothering the user about it?

Gimp-developer mailing list

Re: [Gimp-developer] New Colors toplevel menu

2005-08-01 Thread Akkana Peck
Joao S. O. Bueno Calligaris writes:
 I am not so sure about Image-Modes , unless tehre is a ubmenu
 Colors-Image to indicate taht thos ewill operate ont eh whole image 
 instead of a drawable. But then, they could just stay were they are.

How about calling it Image Mode rather than just Mode?

Gimp-developer mailing list

[Gimp-developer] New Colors toplevel menu

2005-07-31 Thread Akkana Peck
I've posted a patch to bug 116145 which would move all the color
operations -- currently in Image/Mode, Layers/Colors, and
Filters/Colors -- to a new top-level menu called Colors.
(See the bug for the request and discussion of that.)

If I don't hear any objections I'll commit it in a day or so.

One issue is that it makes for an awfully long menu (see screenshot
attached to the bug). Probably some of the items in it should be
moved to a submenu -- e.g.  move everything that was previously in
Filters-Colors to Colors-Filters? Please post any suggestions
here or in the bug.

Gimp-developer mailing list

Re: [Gimp-developer] Integrated Scripting

2005-06-21 Thread Akkana Peck
Nathan Summers writes:
 On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote:
  different levels of artificial intelligence; are there opinions of ways
  to rearrange the Xtns portion of the menu system?

Great topic. Personally I'd love to see the Script-Fu and Python
entries go away, for the same reason as in the Filters menu:
the user shouldn't have to know.

  people rearranging the menus now do not seem to see that Xtns
  makes its own image and do not need to start with an image; even
  though the logic is very clear to some.
 The thing is that there are plenty of exceptions to that rule. 
 File|Dialogs being a big source of stuff that doesn't need an image,

File-Dialogs doesn't make a new image. I'm with Carol, most of the
stuff in Xtns makes a new image, and should be grouped together

 for example.  I know that the reason for the difference is that the
 Dialogs are implemented by the core, but why should I care?

You shouldn't.

  include a menu entry for each of the gimp script powertools:
  the browsers
  the consoles
  the servers
 I see little reason why these shouldn't be a subcategory of the other
 dialogs.  The name Development was suggested.

Right. If it were up to me, I'd split Xtns into two menus:

1. Development (or something similar): all the entries that have to
do with mechanics of the languages (including C). It would look like:

   Module Manager
   Plug-in Browser
   Procedure Browser
   Unit Editor
   Script-Fu Console...
   Refresh Script-Fu
   Start Script-Fu Server...
   Python-Fu Console...
   Python-Fu Browser...

2. All the things that actually make new images. I don't know what
to call this menu. Xtns or Misc or Generate (because it generates
new images) or Create or New Images or ??  This would include all the
submenus that are currently under Script-Fu, without any reference to
the word Script-Fu. Any Python scripts (or C plugins or anything else)
that gets added would merge into these menus too.

There was some suggestion on IRC that not all the items in the
Xtns-Script-Fu submenus create new images. I haven't gone through
them yet to look for counterexamples; if there are some, maybe they
should go somewhere else. Likewise, if there are items in Filters
which create a new image rather than working on the current one
(I don't know of any) then they should move here.

I'd lean toward making both these menus top-level menus in the toolbox
window (so there would be four menus, not three), but that would cause
space issues in verbose languages and large fonts, so alternately,
I'd make Development a submenu (probably of File or File-Dialogs, not
of Xtns/Generate/whatever, since the Development items do not create
an image). It's more important that the New Image Creating stuff
be easy to access than that Development is, because anyone
developing scripts for gimp knows enough to use tear-offs, or
set up key bindings, or somehow make it easier to get to the
language tools.

 Kevi? is certainly not the only one qualifed to change the locations
 the scripts register under.  It's actually a trivial change for

I'd be happy to do the work if we reach consensus on what should
be done.

 Well, no one has experienced all of the gimp experience.  That's
 what good old fashioned kibitzing is for.

That's also what discussion on mailing lists, bugzilla and IRC are
for. We still won't encompass the whole gimp experience, but at
least by doing things in the open we'll have a chance of hearing
from a range of people.

 My suggestion is that Xtns menu items that create images should be
 called something like File|New Generated Image and that the rest
 should be merged with the other dialogs, ether as File|Dialogs or as a
 new toplevel Dialogs menu item.

I'd argue for that menu being a toplevel menu, so users are more
likely to explore it.  There are some cool scripts in there.

There's some reorganization that could usefully be done inside that
menu as well. Buttons only has two items, Misc only has Sphere,
Utils only has two items. How about moving those five items up to be
directly visible in the Generate/Create menu?

So it would look like this:

  Make Brush
  Web Page Themes
  Custom Gradient...
  Font Map...
  Round Button...
  Simple Bevelled Button...


Gimp-developer mailing list

Re: Akkana Menu patch [was Re: [Gimp-developer] The GUADEC meeting]

2005-06-07 Thread Akkana Peck
Alan Horkan writes:
 I was thinking fo doing something similar for the python plugins (and

It was my intention to include python-fu as well. I must have missed
it because python-fu didn't get built in the tree I was using (it's
there now). I need to make an updated patch anyway, to include
placeholders, so I'll merge in the python scripts (there don't seem
to be very many of them) at the same time.

Nobody's commented on any of the other questions I asked in the bug,
like whether it would be a good idea to fold the short Glass Effects
menu into Light Effects, or moving Enhance up to where it's just
under Blur, or whether there's a reasonable place for Show Image
Structure since it's now the only item in Utils.
I'll go ahead and move Enhance since no one objected; maybe I'll
try to come up with some place to stick Show Image Structure.

(The bug is if
anyone wants to comment there or read the questions in more detail.)

 making sure to add ellipses where needed).  However some of the python
 plugins duplicate existing functionality so putting two Clothify plugins
 beside each other would only confuse users.  I see Akkanna tackled this by
 marking the Script-Fu unsharp as Unsharp 2 but if people have idea on
 how to tackle this duplication of functionality I would be interested to

I'd be interested too. I don't like Unsharp Mask 2 but strings
like Unsharp Mask (script-fu) are likely to make the menus too
long. Anyone have a better idea?

Joao S. O. Bueno Calligaris writes:
 People suggested that an icon before menu entries would cause to much 
 hassle to the UI - and I agree. 

Probably. It would be a nice idea but probably isn't worthwhile if
it doesn't plug in easily to the current menu code.

I do like the idea of being able to find out where a particular
menu item comes from.

 I suggested them that right-clicking 
 on a menu item would bring some information about it. (Like:  the 
 package where it came from, what language it is written in, and maybe 
 even accept a new shortcut for that item, without having to enable 
 dynamic shortcuts)

The problem with that is that many people still use right-click to
get the menus (you have to, if you want tear-offs, so I find I get
in the habit of using right-click most of the time instead of left
clicking in the menubar), and once I'm in a context menu which I
brought up by right-click, I expect right-click to continue to work
to invoke submenus and menu items. If that changed and suddenly
right-click did something else, and probably dismissed the menu at
the same time, it would take quite a while to relearn those habits
(and would make gimp's context menus inconsistent with most other apps).

I could see using a modifier key, e.g. control-click on a menu item,
or even mouse over a menu item and hit some key (f12 for help? ctrl-i
for info?) Except of course then you couldn't rebind that key any
more as a keyboard shortcut, so that's probably not a good idea either.

And neither a modifier-click nor a help key over the menu is very
discoverable. Tooltips would be discoverable, but they'd get in the
way as you explore the menu system.

Gimp-developer mailing list

[Gimp-developer] Re: [Gimp-user] use of the Space key

2005-05-24 Thread Akkana Peck
Sven Neumann writes:
 I consider to change what GIMP uses the Space key for and would like
 to get some user feedback on this. Currently, pressing the Space key
 temporarily switches to the move tool.

Spacebar to switch temporarily to move is awfully useful. I didn't
know about it until this discussion, but I've often wanted something
like that -- I'm forever switching between move and something else,
for instance when I'm creating lots of different text layers and
need to position each one. If you change spacebar to pan, I hope you'll
consider investing some other key with this temporary move tool
meaning. Now that I've known about it for a couple days I'm already
sorry to have to give it up!

Do a lot of gimp users not have a middle mouse button? Maybe tablet
users who don't want to put down the stylus and switch to a mouse?
(That would be understandable.) Or is this just because ... that
other program does it that way, and its users are used to it?

Gimp-developer mailing list

[Gimp-developer] Menu reorganization

2005-05-07 Thread Akkana Peck
I haven't seen anything in a while about the menu reorganization
which was proposed a while back.

One thing I'd like to see is getting script-fu and python-fu items
out of separate menus and integrating them into the regular menus,
so users don't have to know what language something was written in
to find it.

With that in mind, I've started from the current Image menu reorg
page and made a few changes:

- Reformatted a bit, in plaintext.  The stuff on the wiki is html
  but it's really inconsistent, has paragraph tags inside list
  items, and closes lists at the wrong place, so it doesn't show
  the right hierarchy and is impossible to copypaste properly.

- Moved script-fu items into the main menu and got rid of the
  Script-Fu menu.

- Combined Animation and Animators: it seemed confusing to have

- Put the Alchemy scripts under Artistic.  They're not really
  Artistic but they do vaguely similar things.

- Distributed the few items in the Python-Fu menu to places that
  seemed vaguely reasonable.

I ended up with 2 more items under Filters than are there now.
Admittedly that's still a lot; some of these could be combined,
but since it's only two more items and I was trying to change as
little as possible, I didn't try.

I only looked briefly at Xtns.  Really, I think that menu is fine
except that again I'd get rid of the language menus, and put the
script-fu stuff under Render.  That seemed so simple that I didn't
bother to write that up as a proposal.

So here's my proposal.  Does it look reasonable?  I tried to compare
it both to the existing menus in 2.2.6 (haven't compared with CVS
yet) and to the proposal on the wiki, but things got confused with
the re-editing I needed to do so I might have missed something.

I'm willing to do some work to make this happen, if people agree
that it should happen and if it's not too late to get it in for 2.4.
I think most of the work involves tweaking script-fu and python-fu
registration routines.  Is there documentation that would need to be
updated?  The menu page on the gimp manual doesn't seem to mention
script-fu or python-fu menus at all.

This seems to be covered under bugs 116145 (image menus) and 145507 (Xtns). 
The latter has a patch from Carol which might be slightly stale now,
but also makes reference to bug 158980, to make a logo browser which
would move the logos out of Xtns.  That's a great idea, but until it
happens, moving the scripts is probably still reasonable.



Image Menu
* New
* Open
* Open as Layer
* Open Location
* Open Recent
  o (list)
* Save
* Save as...
* Save a Copy...
* Save as Template...
* Revert...
* Mail Image...
* Print...
* Close
* Quit

* Undo
* Redo
* Undo History
* Cut
* Copy
* Copy Visible
* Paste
* Paste Into
* Paste as New
* Buffer
  o Cut Named
  o Copy Named
  o Paste Named
* Clear
* Fill with FG Color
* Fill with BG Color
* Fill with Pattern
* Stroke Selection
* Stroke Path
* All
* None
* Invert
* Float
* By Color
* From Path
* Selection Editor
* Feather...
* Sharpen
* Shrink...
* Grow...
* Border...
* Rounded Rectangle...
* Toggle Quick Mask
* Save to Channel
* To Path
* New View
* Dot for Dot
* Zoom (XX%)
  o Zoom Out
  o Zoom In
  o Fit Image in Window
  o Fit Image to Window
  o 16: 1 (1600%)
  o 8:1 (800%)
  o 4:1 (400%)
  o 2:1 (200%)
  o 1:1 (100%)
  o 1:2 (50%)
  o 1:4 (25%)
  o 1:8 (12.5%)
  o 1:16 (6.25%)
  o Other...
* Shrink Wrap
* Fullscreen
* Info Window
* Navigation Window
* Display Filters...
* Show Selection
* Show Layer Boundary
* Show Guides
* Show Grid
* Show Sample Points

* Snap to Guides
* Snap to Grid
* Snap to Canvas Edges
* Snap to Active Path

* Padding Color
  o From Theme
  o Light Check Color
  o Dark Check Color
  o Select Custom Color
  o As in Preferences

* Show Menubar
* Show Rulers
* Show Scrollbars
* Show Statusbar
* Duplicate
* Mode
  o RGB
  o Grayscale
  o Indexed
* Compose
* Decompose
* Recompose

* Transform
  o Flip Horizontally
  o Flip Vertically
  o Rotate 90 degrees CW
  o Rotate 90 degrees CCW
  o Rotate 180 degrees
  o Guillotine
* Canvas Size
* Fit Canvas to Layers
* Print Size
* Scale Image
* Crop Image

Re: [Gimp-developer] Save As remembering last dir (was: we need more documentation)

2005-01-11 Thread Akkana Peck
Sven Neumann writes:
 Mitch and me also agreed that we would like to do something about and even get that
 change into the stable branch. The fact that the file-chooser in GIMP
 doesn't remember the last used folder in GIMP 2.2 was probably a wrong

I don't know if you're soliciting votes, but it would be a huge
help if the Save As dialog remembered the last location, as the
bug suggests.  I hit this nearly every time I save a file.

Is someone already working on it, or do you need a volunteer?

Gimp-developer mailing list

Re: [Gimp-developer] jpeg-exif development summary

2005-01-08 Thread Akkana Peck
Sven Neumann writes:
 Assuming your camera adds EXIF info, are you seriously telling me that
 you do not run 'exiftran -a -i' on each and every image you ever shoot
 and instead use GIMP to rotate them?

Add another voice to all the others saying No, I leave my originals
untouched, and only edit copies.

In fact, I don't think I'd ever met anyone who regularly ran
exiftran on every archived original, until this discussion. 
Exiftran isn't even installed by default on any linux distro I've
used.  Is it commonly found on mac and windows machines?

(in another message) Sven Neumann writes:
 If the spec says it's ASCII, then we have no choice but keeping it
 ASCII. That of course means that there isn't much point in allowing
 anyone to edit this field since conversion to ASCII will fail for
 almost all strings that a user may enter. It appears that the best we

It's a bummer that it's not something like UTF-8 (and quite odd,
if the spec came from Japan), but editing ASCII is still useful
for quite a large number of people.

What do modern cameras sold in Japan save in the EXIF fields?

Gimp-developer mailing list

Re: [Gimp-developer] Re: (LONG) Problems with the GIMP

2003-07-21 Thread Akkana Peck
David Neary writes:
 Sven Neumann wrote:
  David Neary [EMAIL PROTECTED] writes:
   2) Not enough developers use Bugzilla to find out what bugs need
   3) Not enough developers hear user complaints

I'd like to chime in here and say that gimp seems much more responsive
than most projects to bugzilla.  Some bugs may get closed or duped,
and I may not always agree, but I don't think I've ever felt like bugs
were being ignored the way they are in a lot of projects.  And that's
even without the other channels like IRC and the mailing lists.

Of course, David didn't actually complain about responsiveness, but
about the number of developers; and indeed, it's only a few developers
making comments.  Is the problem that bugs don't get triaged to
appropriate owners, so that people outside the small overworked
core team might see and fix them?

 Now, let's look at the Owner field - 1 bug is owned by
 grosgood, one by jimmac, 2 by mitch, 2 by Raphael, 2 by rockwlrs,
 and 1 each for sven and yosh. That's 10. Leaving 381 bugs owned
 by that well-known gimp developer [EMAIL PROTECTED]

I found that confusing, too -- it's not what I'm used to in other
projects, where bugs generally have an owner and components have a
default owner, who may also triage new bugs for that component.
I guess the gimp team is small enough or works closely enough that
they feel they don't need that; or everyone wants to see all the bugs.

 The lifecycle of a bug *should* be that a bug gets reported
 against a module, which is owned by the module owner, who [ ... ]

I'm not sure anyone's quite sure of the perfect bug lifecycle.
I've seen at least five different theories tried, and none seem to
work perfectly.  It probably just depends on what works best for a
particular team.

 I'm glad you agree there's a problem with the number of people
 active in gimp development. As I've said a couple of times, the
 module owners don't need to know how to fix the bugs. This seems
 to me like a great way to get people involved in the gimp. I know
 that fixing bugs was how I got involved... I just started
 browsing bugzilla, picked one that looked fairly easy, and
 attacked. So maybe there are 5 people who aren't too confident
 diving into the core, and would like to feel their way around
 with bug reports?

Bugzilla keywords, like helpwanted or blocker, can be helpful here too.
(Does gimp already use these?  I confess I haven't looked, and should.)
For bugs which might be relatively easy fodder, a keyword in bugzilla
and a periodic posting on gimp-developer mentioning the keyword or
requesting help on particular bugs (as I've seen here a few times in
the past) can be a great motivator.

Gimp-developer mailing list