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

[John Lindgren <john lindgren aol com>]

Hi Paul,

Thanks for your response.

I hear what you are saying and I know what it is like to be a member of 
a small, volunteer development team.  Actually, by number of commits, I 
have put more work into my own project of choice [1] than anyone, paid 
or unpaid, has put into GTK+ over the last year [2], and I have never 
earned a cent from it.

That is why I have tried to help out GTK+ by taking the time to debug 
the problems I encounter and to submit patches for them rather than 
simply reporting bugs and expecting other people to fix them.  I realize 
that what is most important to me -- having a stable and lightweight GUI 
toolkit on which to build a cross-platform desktop application -- may 
not be as important to other people.

So ...

Since the current GTK+ developers apparently do not have time to review 
and commit (or reject) my patches even after weeks [3] or months [4], 
perhaps it would be better for all parties if I were given commit access 
to GTK+ and could fix such problems myself.

If the current GTK+ developers are not interested in having me on the 
team, then I really will be forced to consider forking GTK+ 2.x.  If 
remaining a stable and lightweight desktop GUI toolkit is only a 
second-rate goal for GTK+ now, and the focus has shifted to touchscreens 
and flashy looks, then it's not fair to the GTK+ team or to application 
developers like myself to expect GTK+ to be something that its 
developers no longer want it to be.  I think there are enough people 
like me who value what GTK+ 2.x accomplished for the Linux desktop -- 
not to mention its cross-platform capabilities -- and will see to it 
that it is actively maintained.

Oh, and switching to Qt?  Not at option.  I'll stick to GTK+.  :)

-- John Lindgren

[1] http://www.ohloh.net/p/audacious/contributors?query=&sort=commits_12_mo
[2] http://www.ohloh.net/p/gtk/contributors?query=&sort=commits_12_mo
[3] https://bugzilla.gnome.org/show_bug.cgi?id=680059
[4] https://bugzilla.gnome.org/show_bug.cgi?id=673312

On 07/29/2012 09:31 PM, Paul Davis wrote:
> On Sun, Jul 29, 2012 at 8:35 PM, John Lindgren <john lindgren aol com
> <mailto: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.