[Pidgin] #11764: Account Names
trac at pidgin.im
Wed May 5 11:23:18 EDT 2010
#11764: Account Names
Reporter: tristangrimaux | Owner:
Type: enhancement | Status: new
Milestone: | Component: libpurple
Version: 2.6.2 | Resolution:
Keywords: account name |
Replying to [comment:14 manski]:
> Replying to [comment:12 tristangrimaux]:
> > Sad is the use of the XMPP on the server side, but the good thing is
they implement enough to let the client use any standard XMPP client.
> What do you mean by this? The use of what?
Facebook's implementation of the XMPP protocol falls short on many
aspects. But I'm really glad they didn't come up with a new protocol and
that the Facebook team finally put together something that any standard
XMPP client can use. This comment might go very off topic, please forgive
> > Yes! And instead of implementing another XMPP protocol, it could be
implemented as Account Types.
> I fail to see the difference between "account type" and "protocol".
Aren't they the same (for most protocols other than XMPP)?
This is also material for another ticket, but what I think is this:
Protocols are fine, and nothing is changed on the protocol classes as they
have what is needed to connect, so a new thing can be created:
AccountTypes. A place to put default values for new accounts. When
everyone invented their own protocol this was not thinkable, but when
there is so many services using XMPP you can think of this:
MSN Account type: creates an account with the MSN protocol, the MSN icon,
the msn server filled and something else.
MSN Anonymizer type: creates an account with the MSN protocol, a modified
MSN icon with a bunny (it's an example) the msn server icon and a public
proxy. I don't know if this is very useful, but anyone can think of
something better. An admin could create an account type using he's company
Facebook account type: creates an account with the XMPP protocol, icon,
server, tls unchecked, and so.
GTalk account type: creates an account with XMPP protocol, icon, server,
There is a lot that can be done on this aspect, only by filling
automatically things on very well known protocols. But there are
attributes needed on the account to hold those values: The account name
that might be filled with something like ''My account on Facebook'', and
the icon, of course. It is important to see that if you let the name to be
the name of the account and not the name of a ''protocol'', you allow the
user to give the real meaning of that account. It could be having multiple
accounts on the same service and namimg them to help identify what they
are: ''My Business Account on MSN'', or ''My Social Account on GTalk''.
Easier to implement would be Account Templates, so the account type is not
stored in the account class, its just a way to fill things the first time.
A new window could get implemented to add those account types asking only
for the minimal things: user and password. The rest can be modified from
the account dialog.
The condition needed to do ALL of this is: the inclusion of a local
account icon and a local account name on the account class.
> > The local account icon will fit nicely
> > * as a an emblem over the buddy icon (like nautilus) in the chat
> > * in the toaster popups as you mentioned
> > * when adding a buddy, as it will illustrate better than the
protocol icon in which network is to be added that buddy
> > * when editing the accounts
> > * on the menu
> I think the differentiation between "protocol icon" and "local account
icon" would be nice but I think for the moment it would be easier to allow
the user to adjust the "protocol icon" instead of adding a new icon type
(which would require a lot more changes, wouldn't it?)
Indeed, I think the protocol icon is not needed. Not really because the
user does not need to know he is using XMPP, he just wants to use
Facebook, or GTalk or That-Server-There. But it would be very ungratefull
not to show any sign of the real marvel that is slowly dethroning the MSN
> > The most important part is the local account name. Once that property
appears on the class everything starts to fit.
> Actually, I think the customizable icon (however it'll be implemented)
is more important, don't you think. At least, they're equally important
The name is important only from a logic perspective. The final usability
of course will be the use of an image. The Account class is missing an
important property that nurtures what you can do with a class: the name.
Ticket URL: <http://developer.pidgin.im/ticket/11764#comment:15>
More information about the Tracker