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

List:       kopete-devel
Subject:    Re: [Kopete-devel] [Long] next release
From:       Daniel Stone <dstone () kde ! org>
Date:       2002-04-29 6:45:06
[Download RAW message or body]

On Mon, Apr 29, 2002 at 02:34:05AM +0200, Andres Krapf wrote:
>  - one-to-one chat working well and consistently across all plugins. to 
> achieve consistency, all plugins should be using the KopeteChatWindow (and 
> the KMM, if possible... this brings extra stuff like queuing and notification 
> for free to the plugin writers). a basic chatwindow will do, no need to 
> address the KCW subclassing issue yet.

Not just "if possible", IMHO this should be an absolute for release. I
have Jabber working perfectly with KMM, and thus consider anything not
using KMM a showstopper.

>  - one-to-many should be left for after the release. why ? because of the 
> added complexity. we should concentrate on doing one thing well. or else the 
> different plugins will be in different shapes when release time comes. that's 
> very unsettling for the user. ("what ? i can use this on icq and not aim ?"). 
> plus, there's the fact that some protocols don't support one-to-many, and the 
> infrastructure work will take longer (for exemple, KopeteMessage would have 
> to be redesigned to have toList() instead of to()...). Additionally, the 
> rewards of still doing it aren't that great, because i believe the primary 
> use of IMs these days is one-to-one chats.

I believe it should be implemented if we have time; not of all these
concerns need to be addressed. KopeteMessage doesn't need to be modified
to use toList(), as KCW/KMM can just fire off a series of messages.
Jabber is a special case: it's much like IRC in that you join a
conversation by subscribing to an address, and then you send all of the
messages to that address. For example:
foo@bar.baz joins discussion@bar.baz
bar@foo.baz joins discussion@bar.baz
baz@foo.bar joins discussion@bar.baz
all of the above then send messages to discussion@bar.baz, where it is
distributed to the others.

>  - storing the msn contacts locally and the icq contacts on the server. these 
> are listed in the TODO file. why is this important ? once again, because of 
> consistency. the user expects that basic functionality (group management, 
> one-to-one IM...) will work consistently across plugins, so it should :-)

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.

> basically, just porting all the plugins to KMM is a great, great win. there 
> might be some loss of functionality at first from the user standpoint, 
> because of the subclassing problem. so we won't be able to support, say, AIM 
> warning or ICQ sendThroughServer at the gui level. nevertheless, kopete will 
> become far more intuitive and look more integrated. and also, once a feature 
> is developped for KMM, all plugins instantly benefit from it!
> for example, i've started porting AIM to KMM, and i can now be notified with 
> the balloons and the wav sound. this is very good, because it addresses some 
> of the issues mentionned on the list like "hey this window doesn't popup and 
> i didn't know i received a message".

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.

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.

> consistency is my very first goal for kopete's next release. i do understand 
> that some of these items might be out of control (like when the kxengine is 
> ready for server storing of the users) or some might be hard to do, but i 
> just stated here what i thought would be good for the next release, not what 
> will actually be done :-).

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

-- 
Daniel Stone	   <daniel@raging.dropbear.id.au>   http://raging.dropbear.id.au
KDE Developer	   <dstone@kde.org>	                      http://www.kde.org
Kopete: Multi-protocol IM client	    http://www.kdedevelopers.net/kopete/

[Attachment #3 (application/pgp-signature)]
_______________________________________________
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]