Chris <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 27 Mar 2007 12:31:45 -0400:
> I'm relatively new to this newly rewritten version of Pan as I have been > using the stable version until a couple of days ago. > > In the old version I could select a bunch of groups and refresh the > article counts to give me an idea of which groups are real (ie. used) > and which are not. I can't figure out how to do this in the latest > version (0.125 here). I have to select each group and start downloading > the headers to even begin to determine the activity level in the group. > This is a very tedious process when there may be 5 or 10 similarly named > groups but only one of them is active. > > Did I miss something? I can't figure out how to get the raw article > counts of a bunch of groups real quick like the old version? What you want is the oft requested multi-group select feature back. Charles says it's not trivial to code, but given the popularity of the request, he has said he plans on doing it. Still, I believe that's going to be after 1.0, which was to have happened as early as August of last year, but there turned out to be quite a few more real bugs to work out than anticipated, I guess. That said, I've been expecting it for awhile (I was initially saying by year end for last year, when Charles said he couldn't imagine what would keep it past August... I guess we were both wrong), but Charles naturally wants the big 1.0 to be as bug-free as possible. Meanwhile, there's a workaround, tho it's not as easy as one might like. The first thing to realize is that subscribed or not, any time you do anything in a group, even just update article counts, pan creates file records for it that aren't automatically deleted. If you still have your old pan config around and weren't deleting these things manually, check it. You should see what I mean. Thus, simply checking groups this way isn't and never has been quite ideal, in that even if you never revisit it or check it again, there's that record still around cluttering things up. A second thing to realize is that new-pan honors the $PAN_HOME environmental variable. While the default is ~/.pan2, setting and exporting that variable in the environment pan will use before starting it causes pan to use the new pan config dir pointed to by that variable. The third thing to realize is that while this was originally done to allow users to change the location of pan's config, it ALSO makes it practical to run multiple pan instances, each with its own separate config. Since another issue with new-pan is that all groups from multiple servers get lumped together in the same list, with no possibility of organizing it by group type or subject, and this multiple pan instance thing gives one the ability to work around that as well, I'm actually running two separate pan instances, complete with their separate configs, one for my text groups, one for my binary groups. Actually, I'm running three pan instances, however, the third one being a "test" instance. This overcomes the first problem mentioned above, that of having the record of all those groups only visited once stick around virtually forever. I don't add a group to either my text or binary pan instances until I'm sure I want to keep it around for awhile. I do all my testing in my test instance, where it's easy to clean things up without losing the records for groups I regularly participate in. So... what you may want to do is create a similar "test" pan instance. When you want to check out a bunch of groups, go to your test instance, subscribe to all the groups, and hit the update headers for subscribed groups button. When you are done looking around and have decided which groups you want to really subscribe to, subscribe to only those in your regular pan instance, and blow away the records for your test instance, so it'll be fresh and ready to go the next time you want to test something out. Here are some additional notes on making multiple instances work. For config files that you want to share between instances, symlinks work well. I have a "global" settings dir that contains all such files (including my scorefile and accels.txt, among others), and just symlink them from the individual pan instance config dirs as necessary. For launching the various pan instances, I use little shell scripts, pan.bin, pan.text, pan.test, etc, that set and export $PAN_HOME and do a bit of additional trivial housekeeping. Then, instead of having a single pan desktop menu entry point at the pan binary itself, I have several of them, pan.bin etc, pointed at the appropriate shell script starter. (KDE is my desktop environment of choice, so for me it's kmenu entries. I also have hotkeys setup to launch anything I use regularly, including my various pan instances, and therefore never have to actually open the regular kmenu unless it's for something I don't regularly enough to have a hotkey configured for it. Of course, various other desktop environments should be similarly customizable if desired.) -- 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
