pan-users
[Top][All Lists]
Advanced

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

[Pan-users] Re: Possible to create sub groups?


From: Duncan
Subject: [Pan-users] Re: Possible to create sub groups?
Date: Tue, 23 Sep 2008 04:25:23 +0000 (UTC)
User-agent: Pan/0.133 (House of Butterflies)

Alexander Solano <address@hidden>
posted address@hidden, excerpted below, on 
Mon, 22 Sep 2008 19:50:31 -0700:

> Question:
> 
> Is there a way to create sub groups? Right now when I open Pan (v 0.132)
> I have two options "Subscribed Groups" and "Other Groups". Is it
> possible to create sub-groups?
> 
> I'd like to be able to do something like this:
> 
>> Subscribed Groups
>>> Debian
>>>> KDE
>>>> Kernel
>>> Microsoft
>>>> SBS
>>>> Outlook
>>>> SQL
>>> Other "a.k.a. pr0n"
>> Other Groups
> 
> Well... You get the idea.

Well, it'd not be subgroups, a newsgroup is a newsgroup (and actually, 
each dot can be thought of as denoting a subgroup, much like a / or \ 
depending on your OS indicates a subdir in a file path or URL), but more 
like user arranged categories.

That's not directly possible, but there's a workaround which may actually 
be better, in some cases (worse in others, of course).

In old-pan, before the 0.90 rewrite, each server was managed separately.  
Thus, it was possible to create several fake "servers", all pointed at 
the same real server, but each one named as a category, so using your 
example, you'd have the Debian server, the MS server, the Other server... 
all pointed at the same real server, if desired.

With the integrated server management of new-pan that doesn't work 
either.  But as I said, a workaround...

With new-pan, you can't create categories, but you /can/ have separate 
pan instances, if desired.  Pan checks the PAN_HOME environmental 
variable when it starts, and if it's set, it uses the directory it points 
to as the config and data dir (instead of the ~/.pan2 default) for that 
instance.  It is thus possible to have different configurations for each 
of several instances, each in its own directory.  Here, I have three 
instances, text, bin(aries), and test, but they could as easily be the 
ones you indicated in your example, debian, microsoft, other.

Among the benefits of this arrangement, each instance has its own config, 
so in addition to subscribing different groups in each instance, it's 
possible to set different servers, different connections per server, 
different cache sizes (edit preferences.xml directly for this), different 
posting profiles... all the various things it might make sense to set 
differently.  If you have kids or something and enjoy the "adult" groups, 
the separation, not even having the "adult" groups subscribed in your 
tech instances, say, is of course very useful too.

You can of course run multiple instances at once, if desired.  Here, I 
setup several bash-script launcher scriptlets, pan.bin, pan.txt, etc, 
located in my user's bin dir (so ~/bin/pan.bin...).  Each scriptlet sets 
PAN_HOME and a couple other things (the gtkrc search path var, so it 
comes up themed, not the yucky default colors/fonts, etc) as appropriate, 
then launches pan.  Then in my menu (I run KDE so the kmenu) I changed 
the existing pan entry to point at the pan.txt script instead of 
launching pan directly, and created another one, pan.bin.  (I simply 
start pan.test from the command line when I need it.)  Since I use 
hotkeys extensively, I then setup khotkeys with a combo for each of the 
entries, so I can start it without using the menu.

For the settings, if the particular file is the same across instances, I 
use the same accels.txt (pan keyboard accels config), scorefile, etc, 
across all instances, for instance, it's possible to use a symlink 
pointed at a global settings file, so changing one changes all.

I already mentioned setting the cache size directly in preferences.xml, 
and I have that among other things set differently for each instance.  
Since text posts aren't that big, I have my text instance cache set to 5 
gigs and haven't reached it yet (only a gig or so after two years).  With 
all the configured servers set to never expire, I have messages going 
back (as I said) two years, to the time I set it up, regardless of when 
the server expires them.  It's kinda nice to be able to dig up a post 
from a couple years ago, sometimes. =:^)

With my binary instance cache, I do something different.  I prefer to set 
pan to download messages to cache then go do something else for awhile.  
When I come back, it's finished downloading so everything's local, and I 
can sort thru and save off to final location or delete attachments while 
I still have the post information (author, date, etc) available.  This 
goes fast since it's all downloaded to cache already, and I avoid the 
pain of having to try to sort thru a massive download dir and figure out 
what everything is and where I want to save it, later.  I delete posts as 
I go thru them, so when I'm done, everything's pretty much deleted, and I 
can clear the cache manually, ready for the next download session. Of 
course, pan's default 10 MB cache size doesn't work so well for this.  It 
gets half done downloading the first set and it's already deleting 
stuff!  So I have the binary cache set to a massive 12 gigs, actually, 
the cache dir is a symlink to its own dedicated 12 gig partition.  It 
works well. =:^)

The test instance OTOH has a relatively small cache setting, since I 
mainly use it for temporary subscriptions to check out a group, or for 
checking out specific messages I see people report trouble with here, for 
instance.  Still, the 10 MB default would be WAY too small for the former 
temporary binary group testing purposes since I prefer to download to 
cache first.  I use something like 500 MB or a gig.  Handling this in the 
testing group means I don't clog up the data dirs in the other instances 
with garbage from groups I decided not to subscribe to permanently.  When 
I'm done, I just delete the various data files in the testing instance, 
leaving me with a clean slate for the next time I want to checkout a 
group or try a message someone was having problems with.

So I certainly use the separate instances, each with its own config, 
here.  I'd sure miss it if it wasn't possible to setup that way!  FWIW if 
you're not a bash scripter, here's a copy of one of my starter scripts 
for you to adapt to your own needs.

#!/bin/bash
. gtk_rc_files
export PAN_HOME=$PANDIR/text
cd ~/pan/scraps
exec /usr/bin/pan "$@"

... and the gtk_rc_files file it sources (setup that way so I can change 
the rc setup in one place and it applies to all the scripts, that export 
line is wrapped...):

#!/bin/bash
export GTK2_RC_FILES="/etc/gtk-2.0/gtkrc:/home/user/.gtkrc-2.0:/home/user/
kde3.5/share/config/gtkrc-2.0:/etc/gtk-2.0/gtkrc"

... and ... $PANDIR is set in my bashrc, to ~/pan.  The others set test 
or bin instead of text, so my ~/pan dir has subdirs for each of my pan 
instances.  In addition, it has a globals subdir, with the common 
scorefile, accels.txt, etc, that the symlinks in each subdir point to, 
where all the settings in the file are the same across all instances.

HTH! =:^)

-- 
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





reply via email to

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