Re: GTK 1.2 Tree Item Signal



Jonathan Smith <jonsmith dragonstar dhs org> writes: 
> 
> That is a remark lacking substance and a response that is even more
> lacking in substance.  It has served to handwave his argument that users
> can go to **** and that the maintainers of GTK do not care about the
> quality of their work.
> 

GtkTree predates the current GTK maintainers; it's a very old widget,
one of the first written back in the mists of GTK time. It is
embarassingly broken, yes. I am embarassed about it. For that reason,
4-5 months of developer time were invested in GtkTreeView as a
replacement.

However, because very few people are using GtkTree (most are using
GtkCTree), the decision was made to spend time on quite a few other
features rather than spending a month fixing GtkTree. Even if GtkTree
were fixed to be unbuggy, it has design flaws that render it mostly
useless. So given limited resources it was not a high priority.

If you want to know specific bugs for GtkTree, feel free to search the
list archives and/or bugzilla.gnome.org. Or just give it some good
thorough testing. Mostly they are redraw bugs and segfaults. For the
most part, the cause of said bugs has not been diagnosed, because that
is the month of work that was not done in favor of doing other
features instead. So knowing the bugs will not help you; all we know
is symptoms, such as "does not redraw" or "crashes."

I apologize for GtkTree sucking, but this is open source; if it
really, really pisses you off you are free to fix it yourself. All the
GTK maintainers can do is make a priority queue of TODO items and then
process as much of said queue as they possibly can. If you want to
resort the queue and start working on the top of your resorted queue,
then that would be hugely appreciated.

The problem with fixing GtkTree is not solely that it would take a
month; it's that a) there is no point doing that in GTK 2 (unstable
branch), because we have a replacement and b) the changes generated by
1 month of work in the stable branch would potentially break programs
that have already worked around tree bugs, i.e. that much code churn
in stable is deemed a Bad Idea in general.

So, I'm sorry GtkTree sucks, but priorities have to be set, and
there's only so much time in the day. At least you have the source
code, so you aren't a slave to other people's priorities if you would
like to see some specific work happen.

Havoc




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]