[Top][All Lists]
[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