Fwd: Some UI ideas

[Sean Egan]

forwarding my response to the list. Something funky went on with this thread ;)

---------- Forwarded message ----------
From: Sean Egan <seanegan at gmail.com>
Date: Nov 5, 2007 12:01 PM
Subject: Re: Some UI ideas
To: Georgi Kirilov <kirilov.georgi.s at gmail.com>
Cc: gkirilov at mbox.contact.bg, Evan Schoenberg <evan at adiumx.com>


On 11/5/07, Georgi Kirilov <kirilov.georgi.s at gmail.com> wrote:
> I would like to share with you couple of ideas that came to my mind
> recently. I hope pidgin could benefit from them in terms of usability.

I hope so too. Thanks for the idea!

> 1. What about showing tooltip only for the selected buddy?
>   To be honest, I'm addicted to staring at the buddylist and to move the
>   mouse over and over it, and the constantly popping tooltips began to
>   annoy me, so... I cooked up some complex arguments to convince you to
>   make them stop making me crazy ;-)

Haha, I think that a lot of people are addicted to staring at the
buddy list and actually moving the mouse over it just to see the
tooltips. This gets you complete status messages as opposed to just
the first few words, or nothing at all depending on how you have it
configured.

There's a setting in prefs.xml called tooltip_delay that can be set to
0 to completely turn the tooltip off.

> 2. Why not redistribute the fields to avoid duplication?
>   Given the three aforementioned categories, we could classify each
>   field in certain category:

I pretty much agree with this exactly. The "infopane" idea is somewhat
a manifestation of this thought. The only problem (which should be
completely solvable) is  that each protocol provides different
information in different ways. It would definitely be nice to abstract
those differences away, though.

> These are just couple of ideas for minimizing the duplicated information,
> and information out of context. I would like to hear your opinion
> and if it is positive, I could try to write a patch.

Super. We prefer passing around this sort of information in lists of
PurpleNotifyUserInfoEntry. Three types of this are defined in
notify.h. One of those types is SECTION_HEADER, which doesn't appear
to currently be in use, but I'd imagine was designed just for this.
Evan?

Another (perhaps better) approach would be to create well defined
types of user info, and create a new UserInfoEntry type that uses
those enumerated types.

> unsigned short letter;

Awesome sig.