Re: [gtk-list] Gtk 2.0 (was Re: Tracking object deletion)

[Dave Cole <dave edipost auspost com au>]

Raph Levien <raph@acm.org> writes:

> This seems like a good provisional approach, but it makes me uncomfortable
> in the long term. Already, we're starting to see a number of applications
> that need large scrolling implemented as monolithic widgets, including
> gtk_text, Jay Painter's CList, and of course Gzilla.  More applications
> are sure to arise, including a spreadsheet. In addition, I'd say speeding
> up the list display in the file selector should also be a major
> performance priority. I see a lot of duplicated work, limits to
> functionality (for example, the CList can handle embedded pixmaps but not
> embedded Gtk widgets), and in general a lack of modularity. 

I agree completely.  I would like see all of this so I can use the
widget set in applications without having to worry about the size of
the window caused by the application data.  Re. the list widget - this
one has been worrying me for some time too - I just do not have the
time to work on it.

When you start to worry about the modularity and generality of the
code above all other considerations, you have the potential to
undermine the success of the applications that are built on top of the
widget set.

To clarify that point: image trying to build the thread display in the
Netscape news reader window using the current gtk list widget.  Each
row in the list would be a widget which would have to contain multiple
widgets; bitmap, thread depth, various text labels.  Performance would
be so bad that I doubt you could convince anyone to use it.

What you really need is a special widget for this style of display.
All of the contents of the list should be drawn and managed by the
list, not via child widgets / windows.

> Long term, I think the best solution is to make changes to Gtk that will
> enable large-scrolling for all Gtk widgets. This clearly seems like the
> easiest approach for new programmers to understand.

Again, I agree.

> It seems to me that the Linux community deals with about one major 
> compatibilty-impared upgrade a year, with ELF and glibc being the most 
> recent. I don't exactly like it, but this might be the best path for Gtk 
> as well.

If these changes are delayed until there are lots of applications
depending on the widget set, the pain will be much greater.

- Dave

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS dpu s-:+ a C++$ ULS++$ P+++$>++++ L++>+++$ E+>++ W N++ !o K
w++$ O !M- !V(-) PS+ PE- Y+ PGP !t-- 5++ X R tv b+ DI+++ D G
e++ h--- r+++ y++++
------END GEEK CODE BLOCK------