Re: gdselect alpha 3 [libapt]
On Fri, 6 Nov 1998, Jason Gunthorpe wrote:
>
> Thought exercise:
>
> There are 2200 packages in slink, lets say you display them all. Lets say
> you use a string containing about 50 characters. That is 110k of ram or
> about 10% of the total memory usage.
>
110k (an underestimate, true) is nice to avoid, but not an especially huge
deal IMO... not if it's the only thing we'd gain. A custom widget behaves
nonstandardly, is a pain to write, etc. GtkCTree is really quite nice if
it can be made to work...
> Furthermore, everytime someone does an operation you have to go and
> rebuild ALL of that data which will lead to a very clunky and slow feeling
> GUI.
>
I was hoping to avoid this, it would indeed be way too slow. The Gtk+ tree
widget lets you set individual rows and cells, and show/hide columns. From
the widget's point of view we only need to rebuild when the tree is
restructured, i.e. when you change the sort order or the order of fields
(which shouldn't be to common), or when you download a new list of
packages (but then download time massively exceeds GUI time).
If I change something about package A, does that potentially impact all
packages? Does changing one thing imply iterating over the entire package
list? That will indeed require the custom widget, or at least some kind of
hack. I was hoping that either a) apt would be able to signal which
packages changed, or b) it would be predictable from the operation which
things might change. Then a change only involves updating the impacted
cells and that is a fast operation.
In the testgtk demo app, rebuilding a two-column GtkCTree with depth 3 and
8400 leaves takes about 1 second on my P166. This is with pixmaps, text,
string copies, the whole deal. So if we go to 7 or 8 columns, but have
only 2500 items or so, it should still be about 1 second. This seems OK to
me for changes in sort order or whenever apt will be downloading stuff
anyway. But if we need to do it whenever a package is marked for install,
it is clearly not acceptable.
> The version I have been fiddling with is highly optimized in this regard
> and uses about 15k of ram for the tree and never regenerates it.
>
If necessary I can Gtk-ize this I guess.
> Hrm, I presume it's important for gtk to have command lines.. Does its
> code leave out ones it does not understand? If so you could just call mine
> on the result.
>
I'll have to look at it. Someone just changed Gnome to use popt instead of
argp, and I'm not sure I know what's going on anymore. Then Gtk does its
own thing separate from Gnome. I'm sure it's possible to make them
cooperate, but it might be a little hacky.
Well I printed out the apt-pkg header files and apt-get.cc and so I'll
read over them and see what I've gotten myself into. ;-)
Havoc
Reply to: