lamprez <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
