One of the most important usability problems with Gimp is the
inability to organize resources such as brushes, gradients, patterns,
and palettes. For each of these, you can designate a set of folders
in Preferences, but everything inside those folders is automatically
loaded at startup, and presented to the user in a flat, unstructured
format. Furthermore, there is no way for an ordinary user to get rid
of any of the resources that come with Gimp, even if they are
essentially useless, such as the famous Green Pepper brush.
Not only does this make for problems in finding the right brush etc
when using the program, it impairs Gimp in terms of developing a user
base. One of the things that some users really like to do, in my
experience, is create collections of resources. This has happened
many times for Gimp, but nobody uses the collections, for the simple
reason that adding resources to Gimp generally does more harm than
good: everything you add makes it linearly harder to find the thing
you want when you use the program.
(Note, please, that I am *not* talking here about making resources
available over the web -- that is also very important, but it is not
the same problem. Here I am talking only about managing resources
that the user already owns.)
This problem has been discussed several times in the past, and
proposals have been made about how to address it. I have been
thinking about it recently, and have come up with a somewhat
different, and I believe simpler approach, which I have begun to study
experimentally. I would like to describe the approach that I have in
mind, and to some degree try to explain why I think it is the right
thing to do.
To make the following description easier to understand, I am going to
talk in terms of brushes, but you should realize that gradients,
patterns, and palettes are handled by Gimp in exactly the same way
(technically, all of them are types of GimpData), and a method that
applies to one will almost automatically carry over to the others.
Here is the idea:
1) You have a "workspace", holding the brushes that you are currently
interested in using. The brushes shown in Gimp's brush picker are
those that belong to the workspace. The user has complete control
over the contents of the workspace -- anything in it can be edited
or deleted. The workspace is saved from session to session, and
automatically loaded at startup.
2) You have a set of extra folders, specified in Preferences. The
brushes in these folders don't automatically belong to the
workspace. To get at them, you invoke a Brush Chooser, which pops
up showing a list of brush folders, and a view, which can be either
a list or a grid. Clicking on a folder causes the contents to be
displayed in the view. Double-clicking on a brush in the view
causes it to be loaded into the workspace. Once a brush has been
loaded into the workspace, it stays there until you delete it.
3) You can also use the Chooser to save a brush from the workspace
into the currently selected folder, assuming you have write
That's basically the story. One of the advantages (as I see it) of
the approach is that it makes very little change in how Gimp is used.
So long as the user stays within the workspace, everything works the
same as now. The only new thing is the Chooser, used to load brushes
into the workspace (or save brushes from the workspace into a separate
At a technical level, the workspace would be represented by the user's
writable brush folder, that is, ordinarily, .gimp-2.5/brushes. This
would be the only folder loaded at startup. The Brush Chooser would
show a simple list of the other directories specified in Preferences
(including the set of distributed brushes), and a DataFactoryView of
the directory among them that is selected.
At the level of programming, the only relatively difficult thing is to
create the GimpDataChooser widget. Even this is simple in principle,
although complicated in practice because it involves a lot of rather
complex Gimp code. I have been experimenting with writing a Chooser,
and I believe I have gotten through the hardest part, although there
is quite a bit of refinement needed.
Comments and questions are welcome,
Gimp-developer mailing list