"William Skaggs" <[EMAIL PROTECTED]> 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.

Gimp-developer mailing list

Reply via email to