Hi, "William Skaggs" <weskaggs@xxxxxxxxxxxxxxxxxxx> writes: > I'm not just making this up, I'm reporting my own repeated > experiences. I feel ten times as productive working on plug-ins as > working on the core. This isn't because plug-ins are intrinsically > easier, it's because the api docs are so wonderful. When I'm doing > plug-in hacking, I constantly have the api docs open (for GIMP and > Gtk), and spend probably half of my time navigating around in them. > When I run into libgimp features that are not documented, I'm nearly > as helpless as when working with the core. (For example, the Pixel > Fetcher. If I ever needed to use one, I would be screwed.) Perhaps you should start using the code instead of the API docs. I almost never use the API docs, not when working with GIMP, nor with GTK+ or other libraries. I find it a lot easier to read the code than having to rely on API docs that are often incomplete, not detailed enough, sometimes even wrong. Of course I see the usefullness of API docs. We wouldn't have started to generate the API docs for the core if that wasn't the case. But you shouldn't overestimate them. It can take you a lot of trial and error to figure out how an API really works when instead you could have looked at the implementation or some code using the API. > Let me again be concrete. Consider the problem of making item > displays (brushes, patterns, etc) hierarchical instead of flat -- > something that is extremely desirable. In principle it shouldn't be > so hard if you understand how to use tree view widgets (which I do, > although I don't like them particularly). And in principle the GIMP > hierarchical organization should be very helpful, because it means > that most of the work can be done in a few places. But in reality it > means that only Mitch has any hope of doing it, because it involves > making changes in (if I remember correctly) GimpDataFactory, > GimpContainerTreeView, and/or GimpContainerEditor, all of whose > roles and interactions are undefined, and all of which are inherited > by many different things, with no explicit rules for the ways they are > used. The result is that any change is a shot in the dark, which will > probably break things all over the place. Well, let me assure you that it used to be a lot worse. With the current framework it is at least possible to do it (and I hope we can get something like this done for 2.4) while before it has been basically impossible. Only a few changes would be needed to allow nested containers and a lot of the existing can continue to be used w/o any changes. That's the advantage of an object oriented design. On first sight it might add some complexity. For the size of GIMP our object hierarchy is actually pretty flat and in large parts straight-forward. We only use a handful of design patterns. Sven
