Re: Hello, some of us still care about memory usage

[Paul Davis <paul linuxaudiosystems com>]

On Sun, Jul 29, 2012 at 8:35 PM, John Lindgren <john lindgren aol com> wrote:

Might I suggest putting less time into making things look flashy, and more time into making them work well, if you are short on developers?  CSS theming may be cool, but I would rather have a working GTK+ 3.x for Windows than any of the theming improvements that have been made recently.  The latest news I saw from the GTK+ front (don't remember if it was for 3.4 or 3.6) was that it was going to be possible to theme windows differently based on whether they had focus or not.  Really?  Stuff like that is more important to the GTK+ project than fixing outstanding bugs?

As an edge dweller on GTK development, I think that it is really important for people who want to contribute (or already have contributed) code to GTK to understand some basic aspects of GTK development. You won't find these out by reading this mailing list, or even gtk-devel which is really the correct list for issues related to the development *of* GTK (rather than development *with* GTK). You won't even find them out by spending a short time on IRC or by perusing bugzilla. I'm not even sure there is a single, canonical set of basic aspects, but let me pass along my impression of them after 12 years of code development *with* GTK and a few years doing minor bits and pieces on the OS X backend.

Please keep in mind that the actual core developers of GTK may have a very different perspective than the one I describe below.

1) There are less than half a dozen people involved in day to day development and maintainance of GTK. Depending on precisely how you count this, the actual number might be in the range of 2-4 on any given day. In addition, very few people are paid to work on GTK, which means that some of what happens in the development process is driven by personal preference rather than a coordinated plan to use developer resources in the "best possible way".

2) Almost nobody working on the core development and maintainance of GTK is interested in the specifics of supporting any platform other than Linux (and to a large extent, Linux with the X11 backend). The expectation is that if this support matters to people who develop *with* GTK, then people will step forward to take on these roles OR that no key individuals are required and support for other platforms will happen as a sort of meta-distributed process. This is not to say that the people working on the core development and maintainance of GTK do not *care* about those other platforms, or that they do not want to see GTK work very well on those other platforms. It is simply a statement about their ability (and desire) to actually put their own time and effort into such things, given their other responsibilities. Right now, the evidence is fairly mixed for the meta-distributed process approach.

3) The conception of what GTK really is can change subtly over time. 10 years it was clearly a GUI toolkit designed for developing desktop applications. As mobile platforms (read: small screens), desktop applets and touch interfaces have become more and more common, some of the intellectual energy that was once focused on ensuring that GTK was improving as a desktop application toolkit has been directed into different, newer issues. This doesn't necessarily mean that GTK can't be used for doing full scale applications anymore - far from it, in fact. But it does mean that if you arrive in GTK development having been using it to develop full applications, you might be surprised to discover the amount of effort going into things not particularly central to that kind of development.

4) Because of the limited developer resources, the moment you transition from thinking about developing  with GTK to developing or bugfixing bits of GTK itself, it would be wise to consider yourself an instant member of the GTK development team. What this means in practice is that you do not imagine there to be a group of people out there whom you need to reach out to in order to get stuff done, but that instead *you* are the one who is going to make it happen. This doesn't apply to actual commit access, and its true that on occasion, someone will report a bug or describe an issue and an existing GTK developer will step up and take care of it. But increasingly, if you identify stuff that needs doing, you are likely to be person who is going to have to make it happen. There is very little spare bandwidth in the GTK development world.