Re: gdselect alpha 3 [libapt]
On Fri, 6 Nov 1998, Havoc Pennington wrote:
> 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...
Probably true considering this is X only. The orignal target was lower end
machines to have acceptable performance that's why I'm kinda concerned.
Right now it takes 800k (urk!) of ram to store the ram package
information, this block is mmap'd in directly off the disk for fast load
times.
> > 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.
>
> 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
Yes pretty much. If you change A then all packages that depend on A either
directly or indirectly may change from a working state to a non-working
state. Furthermore if you apply an operation like an auto install then A,
all packages A depends on and all of their reverse dependants (indirect
and direct!) may change state.
The effects of small operations are wide and not easy to predict in
advance. The effects of large operations such as the Problem Resolver are
impossible to predict and possibly effect every package.
I'm actually very surprised that gtk does not offer an owner draw tree
widget item. That's something that is very important in alot of
applictions.
> hack. I was hoping that either a) apt would be able to signal which
> packages changed, or
This is really the only viable option, but I'm not sure it's really a good
idea, some of the algorithms work on a progressive refinment of the
dependency matrix so they will cause many, many state changes as they run.
The system was designed to run most effeciently with an owner draw tree
item displaying a portion of the data structure.
Jason
Reply to: