On Fri, Sep 27, 2002 at 12:04:48AM +0200, Anders Lund wrote:
> Hi All,
Hi Anders,

> I don't attach the patch, since it is full of private comments, and I am in 
> the process of cleaning it up atm, but if anyone is interrested (Tobias?) I 
> can post it or send it privately.
Yes, please send me a copy. Are there any cvs conflicts during a update
with CVS HEAD?

> The patch now adds the following features:
<schnipp>
Sounds cool :)

> Still to be done - apart from cleaning up/optimizations - is
> * Embedded editing. For a start I want to be able to embed a [multi]line edit
>   and start/end the editing, including sending some signal so that the host
>   application can store the edited value.
Editing shouldn't be done in the views. We have the QuickEdit for it and that
is the right way IMHO.
If every view try to provide editing capabilities we'll end up with a lot of
duplicated code and many additional bugs.
So please drop this item from your TODO list ;)

> * Optimizing the way KAddressbook handles views - currently they gets cleared 
>   and recreated way too often - for example if a single contact is edited, the
>   entire view is recreated - what a waste;).
I can't follow you. If you edit a entry be selecting 'Edit Entry' or
double clicking a item (e.g. card) the appearing AddresseeEditorDialog is
already cached.

> * Make it designable
What do you mean with designable?

> It is still my opinion that the field list should be global, that is kept in 
> the card view rather than in the individual items, apart from using less 
> memory it is also an indication that each card should contain similar 
> information.
If it breaks nothing than I've no problem with keeping the field list in
CardView.

> Note that I do not currently use double buffering. I could easily adapt
> double buffering as used by the current HEAD cardview, and I do have
> flickering here, though I haven't seen problems with missing redrawing as
> some have complained about.
Yes, please use the double buffering code from CVS HEAD. It uses
  viewport()->setBackgroundMode( NoBackground )
to avoid flickering.

> Anyway, I hope this patch can be accepted immediately after the freeze is
> over (for 3.2)?
I would like to test it before giving any promise ;)

> I am working on a filter system that allows to define trees of filter rules, 
> it can be pictured like this
> SET name=STRING scope={AND|OR}
>   RULE|SET
>   [...]
> [RULE|SET
> ...]
> 
> where a rule works like this:
> RULE field=KABC::Field method={Is|IsNot|Contains|DoesNotContain|(etc...)} 
> [test=STRING]
> 
> The filters currently use only string comparison, since we still does not own 
> any kind of type checking of fields.
That sounds quite complex. Lets see how you can hide it behind a meaningfull
and easy to use GUI.

> Is anyone interrested in helping with this, or seeing the premature code? let 
> me know.
My TODO is already big, but maybe I'll find time for it.
ATM I'm very busy with non-programming :(.

Ciao,
Tobias
-- 
In a world without walls and fences who
needs Windows and Gates???
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/