Direction of Pidgin development

[Casey Harkins]

Dale Worley wrote:
> The bitter reality is that if your software is going to be widely
> adopted, the average user isn't going to be very knowledgeable.  Some of
> them are stupid, of course, but most of them just don't have the time to
> study up on the software, especially on how it works.  As a rule of

Even highly knowledgeable users typically want things to "just work". If 
I need to make my software do something special, I'll invest the time to 
do so. For most of the software I use, I prefer that it just work in a 
reasonable manner (as is the case with protocol icons issue).

> The deep problem is that the plugins are affecting the configuration UI
> in a way that makes it harder to navigate.  Or you perceive that, but in
> this sort of issue, the perception *is* the reality.  That suggests that
> not enough study has been put into the various subordinate windows, how
> they are organized, and how they interact with each other.  It's a tough
> task (but vital) that when a plugin is added, its interface elements get
> integrated into the interface in a way that makes deep sense relative to
> the logical structure of the interface.  I suspect that right now, the
> added interface elements are organized based on which plugin supports
> the element, which may not correspond to the overall *logical* structure
> of the settings.

This is probably the best point I've seen come out of this discussion 
(aside from the justification for not needing protocol icons on the 
buddy list) and I'd certainly like to see suggestions of how plugin 
preferences could be more logically grouped/presented with the main 
pidgin prefs. The UI for such a prefs system would be challenging to do 
well.

-casey