Making Pidgin small-screen-friendly

Etan Reisner pidgin at
Sat Feb 21 10:38:42 EST 2009

On Thu, Feb 19, 2009 at 02:34:27PM -0500, Michael Terry wrote:
> == Conversations Tab ==
> 1. Drop the Font section.  The 'Default Formatting' section already
> allows changing the font face and size and reverting to the desktop
> default.  The only loss is that getting back to 'default' size isn't
> obvious, since there's no feedback on when you have modified the size.
> Not sure if that's a deal breaker; we could clarify that in the current
> UI by making 'Smaller' or 'Larger' checked when the font is smaller or
> larger.

Fine by me, I've hated that preference ever since we added it. The
'Conversation Font' preference just papers over an ugliness involved with
a 'feature' I've never liked anyway.

Changes to the outgoing font size should show in the demo input area, as
such reverting to the defaults should show as well, though nothing
indicates 'these are the defaults'.

> 2. Move the 'Default Formatting' section to the 'Smiley Themes' tab and
> rename the tab to 'Theme' or 'Appearance'.  The smiley theme selector
> can shrink safely.

There are already plans to make the Smiley Themes tab a more generic
Themes tab, and I'm not sure this fits in with those plans, nor do I think
the section really fits that concept outside of those plans. Though I'm
open to be convinced I'm wrong about this.

> == Sounds Tab ==
> 3. Drop 'Mute sounds' option.  Is this necessary, since user can choose
> 'No Sounds' as their 'Sound Method'?

The 'Mute Sounds' option was added here because it exists in both the tray
icon right-click menu and the Tools menu and people were accidentally
turning it on without realizing and being unable to find it. But that's
not an opinion on the suggestion as much as a history lesson.

> 4. I don't *think* it will be needed, since 'Sound Events' will shrink
> naturally, but if we need more space on this dialog, move the 'Sound
> Options' section to be to the right of the 'Sound Method' section.

We've avoided side-by-side preferences so far and I'd like to keep that
track record.

> == Network Tab ==
> 5. Move the 'Example:' help text to right of server
> field.

Fine by me, though we may want to consider putting it in the input area
(like the Username help text for MSN accounts) or even just defaulting to

> 6. Have 'Start Port' and 'End Port' fields be horizontal to each other,
> not vertical.

Having it read 'Range: [####] - [####]' certainly seems reasonable.

> 7. Layout Proxy and Browser buttons vertically to each other, move their
> help text to the right of each button.
> 8. Optionally, drop Proxy & Browser section?  Why are these needed
> (honest question, I don't know)?  In what environment do these not just
> link to the desktop proxy or browser preference dialog (as they do in
> GNOME)?  I noticed each account also has its own Proxy setting under the
> Advanced tab.

The browser selection is needed when the user isn't using a desktop
environment like GNOME or Windows. The fact that we delegate to GNOME as
we do has caused a number of users to complain in fact, but isn't
something we think we are incorrect about. Ditto for the proxy settings.
The per-account settings are there in case specific accounts need specific
proxies different than the global proxy configuration.

> == SILC Advanced Dialog ==
> Now, this is obviously a generic dialog that takes the fields from the
> protocol plugin and just displays them.  But maybe we can try to do
> something clever if the plugin is giving us too many fields.
> 9. If a plugin gives 'too many' fields (>= 10?  would hit just Yahoo and
> SILC I think), lay them out in a table.  e.g. If given 10 fields, lay
> them out in a 5x2 grid.

Like in 4 I'd like to avoid side-by-side prefs as long as we can.

> 10. The above is slightly ham-fisted.  It would be nicer if protocols
> could provide groupings of preferences, and maybe they could be layed
> out in different tabs.  But I was looking for a less invasive change
> right now.

Yes, grouped preferences would be nice though I'm not sure tabs of them is
the right idea. I think it might be better to ask if all of the options
listed there really need to exist, and of those that need to exist how
many of them would be better served by being moved to the Accounts menu as
more runtime friendly options.

> == Buddy Pounce ==
> 11. Move 'Pounce when Buddy...' section to the right of 'Pounce on Whom'
> section.  Horizontal space is easier to come by than vertical space.

Aside from my comments in 4 and 9 doing this would require an
unnecessarily wide dialog (since account and buddy names can be long) and
would leave a large amount of vertical space empty since those two entries
will never be as tall as the 'Pounce When Buddy...' options are. (Yes, I
realize the pounce when options break my side-by-side rule but this is a
case of absolute necessity, one I'd like to do without but a scrolling
widget like the sounds page in preferences wouldn't really be any better.)

> 12. Move 'Execute a command' and 'Play a sound' actions to right of
> other actions (two column format again), with their associated buttons
> being layed out below the checkboxes.
> 13. Move 'Recurring' checkbox to right (two columns again).

See 4, 9, and 11.

> 14. Drop dialog separator, possibly shrink dialog spacing a bit (looks
> like it's ending up with a 20 pixel border, but I think you are rightly
> intending it to be 12, per HIG).

Yeah, the separator should probably go.

The largest gain for this dialog could probably be found by making the
'Send a message' action work the way the per-account message stuff works
in the Status dialog, that is have the message shown inline and have it
pop up a dialog for editing. I'm not sure I like the idea but it would be
the most effective single change.


As a side note, I've been thinking about moving the per-account Proxy
settings into their own tab (so we would have Basic, Proxy, and Advanced
tabs) which would help with the dialog height a little bit for the more
"complicated" protocols.

One further thing we could consider regarding the New Buddy Pounce dialog
is that we know that quite a lot of people get to the dialog by right
clicking an entry in the buddy list and selecting Add Buddy Pounce so
perhaps we might want to consider (in that case) not giving people the
account dropdown and buddy entry area but rather just making the 'Pounce
on Whom' text include that account/buddy information in line.


More information about the Devel mailing list