pan-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-devel] Feedback: New prefs dialog layout


From: Petr Kovar
Subject: Re: [Pan-devel] Feedback: New prefs dialog layout
Date: Thu, 26 Jan 2012 22:57:36 +0100

Hi,

Some additional mostly nitpicking feedback. :-)

PREFERENCES

For the widgets placed before the text labels like "Size of article cache",
"File extension...", both items "Minutes to..." in Misc, and "Default
bytes...", let's move these widgets after the text labels, to the right, so
they are placed consistently with widgets in other tabs, e.g. "Colors" or
"Applications". The text labels should then obviously end with ":", not "."

The same for the Hotkeys tab. Also, let's not align the text labels
to the center, but to the left.

If we now have the option "Show only icons.." available, why not also "Show
only text..."? We shouldn't let the user select both options though. :-)

Not sure if this has been already discussed, but the system tray
functionality doesn't work properly in GNOME Shell, although the Shell is
supposed to be compatible with libnotify (which is now deprecated in GNOME
3). E.g. Pidgin or other GTK+ 2 apps with libnotify support work as
expected with Shell. As a result, setting Pan to minimize to the tray
actually closes Pan.

Not sure if we need a special tab for single upload setting. Why not move
it to Misc as well?

Personally, I'm not much into exposing every possible option in the Pref
dialog (hi Duncan! :-), especially as for the Hotkeys settings, I'm pretty
sure people who are into modifying their hotkey preferences can surely
open the right text file in the text editor of their choice. And they
can even search quickly for the their hotkey setting in the text file, which
they cannot do in the GUI. I'd even guess that many advanced Pan users will
use their text editor regardless of what is exposed in the GUI. ;-)

HTML

One of the favorite topics here. :-) 

Currently, the HTML code is displayed in the body pane without any visual
separation from the plain text part. That's not very user-friendly.

I like the approach used in Sylpheed / Claws Mail: the HTML part of the
message is treated as an attachment so users can open the attachment (with a
web browser by default) directly in the client GUI.

Now that we have the Attachments bar below the body pane, I'd suggest
displaying there the HTMl part in the list of attachments/files, so users
can (double-)click and open it in the browser.

Of course, as with other options, this can be configurable. :-)

Anyway, keep up the good work, Heinrich!

Cheers,
Petr Kovar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]