Re: [Evolution-hackers] ... and how camel should be

On Mon, 2006-02-13 at 15:10 -0500, Jeffrey Stedfast wrote:
> This would take several years to implement - likely to require complete
> rewrites of at least some of the providers.
> I don't really see this happening anytime soon.

What about the disk summary branch?

Will this branch have likewise functionality?

Can I be of any assistance? Redoing something like Camel would take me
even more years. So I figured ... if I'm going to need it, my best bet
would be to adjust camel in such a way that it does become like this.

What would that mean for the Evolution team? In the end, Evolution's
memory usage during typical application usage would be reduced. I think
that at this moment a vast amount of Evolutions memory goes into these
design issues.

It "would" greatly improve the memory usage of the header summary view
yet keep it sortable.

The start of the disk summary branch was the right thing to do.

Let's pick it up.

Difficult is fun.

> On Mon, 2006-02-13 at 18:29 +0100, Philip Van Hoof wrote:
> >

Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be -

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