On Saturday 09 June 2007 05:42:48 Olivier Goffart wrote:
> Le samedi 9 juin 2007, Gustavo Pichorim Boiko a écrit :
> > Hello
> >
> > I was configuring kopete, and setting the avatar images, nickname and so,
> > and I saw many different dialogs to configure each protocol account.
> >
> > So, I'm starting to work a bit on this:
> > I'll try to get information that are common to all protocols (like
> > nickname, photo - that might not be available on some, but is available
> > on most, name, etc) and put this in a single widget.
> >
> > For the user info configuring dialog, I'm planning to create it like the
> > ICQ one, configuring pages are selected from the side bar icons, and the
> > first entry will be a common info page for all protocols.
> >
> > I don't know if I made it clear, but as soon as I have something to
> > commit, I will send a patch for you to take a look and approve/reject
> >
> > In the mean time, I would like to get some feedback and ideas from you.
> >
> > Cheers
>
> I think we need to see different categories of fields
>
>  #a) Offline fields:
>       Those that are required in order to connect
> (login/password/server/ssl/...) #b) Online fields:
>       Those that are account option that can be modified only when connected
>  #c) Protocol global config fields:
>         behavioral configuration setting independent of the account
>  #d) Identity fields:
>         fields that probably belong to the global identity (the vcard)
>
> I think that #c doesn't really belong to the account configuration,  it's
> now placed there just because there is no other place to place them.  Where
> to place those settings ?  Good question.  In old version of kopete,
> protocols (and plugin) was able to add configuration page in the kopete
> config dialog. But this has been changed for usability issue IIRC.
>
> #d should be in the identity page, and probably not in the protocol page.
> But what about users that may want to give different information in
> different account ? i think that the multiple identity cover that need.
> What about field that are not available in each protocols ?  (MSN doesn't
> have a full vcard, unlike Jabber)    The identity page should contains all
> fields. If the user doesn't have a protocol that support a field, the field
> should be disabled.

That's why I want to use only fields that are present in most protocols to 
create a sigle interface for that. The configuration will still be 
per-account, the only thing that will change is that fields like Nickname, 
Name, photo, and other ones that I identify as being present in most 
protocols will be placed equally for all protocols, today this is a big mess: 
every protocol does it its way, and it is not a straightforward path for the 
user to find the places where the information should be.

About #a, #b and #c, I'm not worried about them for now, I'm just trying to 
factor out things that are common to all protocols to improve kopete 
usability.
 
>
> Now we have the #a and #b fields.
> IMO, when adding a new account, only #a fields should be shown (maybe with
> #c) But also some field to register a new account
>
> Here was my little analysis :-)

Thanks for you analysis, it is good to have things well discussed before 
implementing them :)

> Now, to reply to your mail,  I think that fields that are common to each
> protocols are only in categories #a and #d.  I've already discussed about
> #d, and there is already the PasswordWidget for #a.

For #a I would not care too much, because information each protocol needs 
might differ, but for sure we should try to keep as most as possible the same 
layout for those too.

My main concern is about #d, beucase today this is a complete mess. Just to 
give an example, the photo configuration of yahoo is not even in the user 
settings page, it is in the account configuration one. But this is not the 
only one thing that is clearly wrong.

Cheers
-- 
Gustavo Pichorim Boiko
-----------------------------------
KDE Developer      www.kde.org
Mandriva Labs      www.mandriva.com
_______________________________________________
kopete-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kopete-devel

Reply via email to