[Pan-users] Re: Switching between servers

[Duncan]

lamprez <address@hidden> posted
address@hidden, excerpted below, on  Sat, 08 Sep 2007 21:40:01
+0000:

> I'd like to see more GUIsh options that refers to functionality of Pan;
> editing configs file with Vim seams to be more oldschool but without
> good manual/documentation it's more difficult than should it be

Well, nothing saying it has to be vim.  I use mc and mcedit for most of 
my sysadmin and config type tasks, but use konqueror and kwrite in some 
cases as well.  Use cat/sed/awk/pipes/shell-redirection for all I care. 
=8^)  (I did once have to use sed to edit a file to get my system back in 
working order.  It was the only thing I could find that was available and 
worked!)

Seriously, tho, the thing with pan is that as a GNOME app, it has the 
GNOME simplicity complex that tends to drive KDE/power-user/control-freak 
type folks (like me... and of course like Linus) to distraction.  
Fortunately, pan doesn't seem to have it to the degree that many of the 
core GNOME apps and platform do, but it's certainly noticeable even so, 
and deliberate policy to a large extent, GNOME or no GNOME.  Many of the 
more complex settings were left out of the GUI this time around, because 
they "are too confusing for many users."  (That's pretty close to a 
direct quote of Charles.)  

Personally, I think the GUI settings dialog is a perfect place for things 
like the max cache size, but it's not there as too complex, and... I 
can't complain /too/ hard as at least it's not hard-coded, requiring a 
compile-time patch to fix.  It's in the config file and that's at least 
acceptable.  Same with expiration.  The GUI has a few hand-picked 
specific settings, but the config file has it in days, set the number of 
days you want.  As I previously mentioned, same with backup server 
levels.  Charles thinks it's too confusing to have more than two levels 
in the GUI, so that's what he put there, but the setting in the file is 
simply a positive integer, so one can set as many levels of backup 
servers as one wants.

Obviously, there's quite a contrast between the GNOME way and the KDE 
way, which would ensure all those setting in their full glory were 
exposed in the GUI.  I prefer the KDE way, but at least they are exposed 
in the file for tweaking, and as with KDE's K3B on the GNOME side, 
there's simply no KDE equivalent of pan on the KDE side, so I continue to 
use pan.

There are a couple other similar settings that have additional reasons to 
be what they are.  The connections per server is limited to four in the 
GUI, because that's the accepted norm, as defined by the GNKSA 
requirements and recommendations, and Charles is justifiably very proud 
of pan's 100% certification and leery of losing it.  Still, for advanced 
users, it's possible to set more connections by editing servers.xml 
directly.  That's new from old-pan (0.14.x), where it was hard-coded at 
four and required a compile-time patch to change.  IMO, Charles took the 
perfect compromise there, as the GNKSA test looks at the GUI, saying 
nothing about the config file, so pan can continue to pass with flying 
colors while giving the folks that are motivated enough to look or ask, a 
way to change it as they see fit.

Similarly, the PAN_HOME environmental setting can't easily be in a config 
file, since it defines where pan looks for the config file, as well as 
its other data files.  However, that's in keeping with a relatively 
strong Unix and even MS-DOS tradition, and while it'd be relatively hard 
to stumble upon without asking or looking at the code, the power users 
that are likely to care are exactly the kind that are likely to know 
where to ask and/or how to look at the code.

All that said, sometimes I think I'll switch to knode for text and 
klibido for binaries, particularly if klibido has continued to develop 
(I've lost track of its current status, and it was only a few months old 
and still a little rough, but developing fast, when I last used it).  
Among other things, that'd pretty much entirely clear my system of 
routinely used GTK apps (pan's the only one), and I could remove it and 
supporting software from my system.  One thing about running ~arch 
(unstable/testing) on a rapidly updated from-source distribution like 
Gentoo, it STRONGLY encourages folks to practice good system hygiene, 
dumping packages they don't use regularly, so they don't have to 
constantly compile updates from source.  It's automated enough it's not a 
big hassle for stuff you use regularly, but unlike binary distributions, 
there's a definite cost in maintaining every package, thus encouraging 
one to unmerge those one doesn't actually use.  If I were to switch away 
from pan, I'd dump my last GTK based app, and could unmerge GTK 
entirely.  That's several packages I'd not have to worry about, which I'd 
consider a GOOD thing.

But... I'm both familiar with pan and consider myself a strong 
contributor to its groups/lists, and I'd be giving all that up if I 
switched.  The pan groups therefore, more than anything else, are what 
has kept me around, and are likely to continue to do so for some time to 
come. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman