Re: GTK 1.2 Tree Item Signal

[steph fox btinternet com]

... *is* the right answer ...

:)

> 
> 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