Libpurple 3.0.0 API suggestions

[Tomasz Wasilczyk]

Pidgin/libpurple is preparing for 3.0.0 (and new API), so we have an
opportunity to introduce some new features. I have prepared a list of
changes, that would make Pidgin better. Please review them.

------

Request API:

- ability to show "please wait" window with optional "cancel" button.
Now, when Pidgin do something time-consuming, like http requests, user
doesn't get any feedback. It can be misleading - user have no
possibility to check if requested task (in example, searching in
public directory) is being processed.

- purple_request_fields should have ability not to close just after
clicking "OK". That would be useful, if entered data have to be
validated before use. Example: user fills in password change dialog
and clicks OK. It turns out, that he incorrectly typed previous
password, email or captcha (required for Gadu-Gadu account). He have
to type in all fields all over again, instead of correcting just that
one. Also, that would be helpful, if there was possibility to display
hints under incorrectly filled fields.

------

Status API:

- new status: chatty (used in jabber, mxit and gadu-gadu)

- extended away (does it means "will be back later?") could not
disappear from status list, when using jabber/oscar/yahoo AND protocol
which doesn't support it. In protocols without support for it, it
could fall back to simple away

------

Protocol plugin API:

- username validation, as in #14649

- restore password - if account cannot connect due to incorrect
password, there could be third button under failure message: restore
password. It could invoke prpl callback for protocols, which
implements it

- "actions" menu could have ability to contain sub-menus for better
items organization

- username vs account number - labels: some protocols, like gadu-gadu
or icq uses account numbers instead of alphanumeric usernames. That's
misleading for new users, when they are asked for "name", while
original protocol asks for "number". Adium uses userNameLabel field.
That could be boolean switch too: number/username. That would be used
only for displaying labels, not validation

- new account check vs new account button - some protocols (like
gadu-gadu) doesn't offer typing in username while registering new
account - they are generated automatically. So it's misleading, if
user have to type in dummy number in username field. That could be
option to display new account button, instead of checkbox for such
protocols.

- looking up for public aliases while adding contact to buddy list.
Some clients have useful feature: when user tries to add new contact
to buddy list, application fills in "alias" field with user's public
alias, public directory name or something like that. That could work
that way:
  1. when adding user from conversation window: user clicks "add user"
(he gets "add user dialog" with filled in username field), libpurple
asks asynchronously for this user's public alias, when it gets
response AND user didn't filled in alias field yet, it gets filled in
automatically (and user can correct it)
  2. when adding user from buddy list window: user types in username,
moves focus out of username field and libpurple asks asynchronously
for alias like in 1.

------

Also, I would like to help implementing it.

Thanks for feedback,
Tomasz Wasilczyk