[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] [Long] next release
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-04-29 8:35:15
[Download RAW message or body]

On Monday 29 April 2002 08:45, Daniel Stone wrote:
> I think that *no* contacts should be stored locally. Why should we care,
> when we can't do anything offline? Plus, AFAIK every protocol supports
> storing the contact list on the server - Jabber does, MSN does, IRC has
> no contact list, and AIM/ICQ apparently do now.

I think *all* contacts should be stored locally ;-)

Why? See Trillian. It has one _briliant_ feature that I'd love to see in 
Kopete, the ability to rename contacts locally. I tend to name people after 
their real name in my contact list if I have the option. Tiny problem is that 
Kopete only shows the nick and has no ability to overrule it locally.
Worse, in MSN you see the MSN id instead of the nick until a user has been 
online. I'm not entirely sure, but IIRC you cannot query a user's name in MSN 
if the user is not online. Caching those names locally would be a big plus.

Essentially KopeteContact should use the name() property for the name in the 
contact list and have a flag hasCustomName() when you override locally. If 
not, name() == nickname(). The flag is needed for several synchronization 
reasons.

None of the above can be done with server-side lists.
Additionally, the list should also be stored on the server for easier 
transport between computers and clients.

> I think the main win from KMM is consistency, and cutting down on
> pointless code duplication. Widgets don't need to be done for this
> release (which I still maintain should be 0.9); I think we should leave
> that for 0.9.1.

Partial support for custom widgets is already in KopeteChatWindow, but the API 
to actually use that needs more thought.

> Which brings me to the next point: more frequent releases. Once we've
> got all the API changes locked in, I don't see why 0.9.x shouldn't have
> a series of dot releases leading to 1.0.0 and inclusion in kdenetwork.
> This will also help us get a lot more testing.

I'd vote for 0.8 being Kopete 1.0 alpha, next will be 0.9 which should be 1.0 
beta and try to be as feature/api complete as possible.

Following that several point releases that polish the API for Kopete 1.0. If 
we can make that we can also make kdenetwork 3.1, but if so we have to act 
_very_ quick. Otherwise we can at least release separate from 3.1 at the same 
time and definitely go into 3.2.

I'm a bit hesitant to freeze the API for Kopete 1.0 though, there are quite 
some longer term features that require BIC changes to the API we likely have 
by the time 1.0 is out. Maybe aim for a BIC-stable API in KDE 3.2 ?

> I think consistency is essential to a good user experience, no ifs or
> buts about it.

Definitely.

Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]