Sven wrote: > Well, that is, please excuse me, very stupid. We aren't putting our > free time into cleaning up the code for ourselves only. We would love > to see more people working on the core and I would very much > appreciate if you could stop spreading this FUD that hacking the core > would be something that only experts could consider to do.
That isn't quite what I have been saying. Some types of hacking on the core are relatively easy, others are very difficult. Rearranging tool options, for example, or changing the anti-aliasing of the ellipse-select tool, are quite straightforward. And some of the difficult things are difficult because they involve fancy mathematics or need to be extremely efficient; there is nothing to complain about in that. The problem is that, in my experience, nearly anything involving the object hierarchy is very difficult because the object interfaces have never been explicitly defined: there is no way to tell what each object class is supposed to be doing except by reading its code and the code of the things that use it -- or by constantly badgering people with questions. 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.) 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. Now I completely understand how huge a task it is to produce such documentation, and I am not at all trying to cast blame. It's especially burdensome because the most important parts can't be done entirely by volunteers -- an explanation of the purpose of an object class has to come at some point from the person who created it. Instead a more proper attitude is that the excellent documentation for the GIMP libraries is amazingly great -- there is no other open source application with anything comparable. (Libraries and toolkits, yes, but not applications.) But I am annoyed to be told that I am spreading FUD when I am simply saying things that in my experience are true. Karine Proot wrote: > I have to back up Sven here. > > I am currently trying to get my nose in the code by submitting patches > to easy-fix bugs. I asked him and other developers very stupid questions > and they always have answered nicely and helpfully. It is quite obvious > that they will help people trying to hack the core, as these very people > can become Gimp developers later, and giving them some answers when they > are stuck is far more productive than doing it for them. It took them > between 15 seconds and 3 minutes to answer each of my stupid questions, > which is far less than the time required to build a tutorial. And above > all, trying to make my way into the code before giving up and shamefully > asking those questions, made me understand the Gimp code a bit more each > time, which you cannot achieve if you only follow a tutorial written for > you. > > The Gimp developers took the time to add 'easy-fix' keyword to some > bugs. This can be seen as a waste of time as they could fix these > themselves in short time, but it would be harder for beginners to help > them and they may lose some help offers. What I am trying to tell is : > if Sven says it's easy, then it is. Maybe you'll struggle with some > parts of the code, but if you try it and ask precise questions when > you're lost I am positive you'll get an answer to help you go on. > > Granted, this takes some time, but it is no duty and you can do it at > your pace (mine is very slow!) > > I hope you will give it another try. I understand why you wrote this, because if you haven't followed GIMP development for very long, my email could easily be read as coming from a newbie who took one look at the core and fled in horror, but the fact is that I have written half a dozen plugins, worked on quite a number more, and made a substantial number of contributions to the GIMP core and libraries (mostly pretty minor). Around July I switched from code writing to writing help docs because I thought that was the place of greatest need, and currently I'm too bogged down in other things to do much GIMP-related (other than write way-too-long emails, damn it!), but I'm not going away. Anyway, thanks for your kind response. Best, -- Bill ______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer