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 permission there. 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 folder). 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, -- Bill
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
