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@xxxxxxx
<mailto:john.lindgren@xxxxxxx>> 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.
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
