[Pan-users] Re: First glance at .100

[Duncan]

"Peter B. Steiger" <address@hidden>
posted address@hidden,
excerpted below, on  Tue, 20 Jun 2006 11:35:27 -0600:

> Lookin' good!  As promised, it's faster, smaller, and able to leap tall
> buildings in a single bound.

=8^)

> Some features I really loved in 0.9x

>From the below, I'm assuming this means <0.9x, IOW, 0.14.x. =8^)

> seem to have disappeared or changed for the worse. Before I [feat-req bug
> these] I thought I should [[] make sure this isn't just a case of Stupid
> User Syndrome.
> 
> 1) You can no longer associate a specific posting profile with each
> group, or designate a default profile.

This is the worst remaining regression for me here, as well. 
Unfortunately, while Charles says it'll eventually be fixed, he says it's a
post 1.0 fix.  That isn't as bad as it may sound for a long time pan user,
however, because 1.0 will be the next stable release.  Charles says the
bug reports are seriously slimming down, but there are a couple minor
additions he intends to make first and of course they'll need debugged. 
In any case, however, 1.0 should be /well/ before the end of the year
(like say August).  I've been saying before the end of the year as I
didn't know his plans for sure and didn't want to get folks' hopes up too
far, but check the other current threads -- he says he wants to know what's
so seriously broken it'll require another 20-some weekly builds to fix! =8^)  

Post 1.0, Charles says expect a few 1.0.x stable series builds to fix
whatever bugs are exposed by the larger userbase of a stable build, then
he'll reset $HEAD to 1.0.9x (or perhaps 1.0.9xx) and the pre-1.1 testing
sequence will begin.  We should be well into it by the end of the year, if
1.1 hasn't in fact come by then (I don't know how fast he intends the
stable release cycle to be so can't yet predict when 1.1 might be).

Back to this regression...  You'll observe that PAN at the moment has
essentially zero per-group state information retained (beyond message
tracking, of course).  There are a number of things that pan <0.90
retained per-group that are no longer tracked, and a number of others that
it would be /nice/ to make per group.  My guess is that one of the reasons
this is post 1.0 is that he doesn't intend to add any per-group state
tracking until then.  When he adds the mechanism to track state per-group,
this and several other features (like the toggle state of the read-message
and other filters) will likely appear more or less together with that
back-end mechanism.

Additionally, Charles mentioned that enough people had trouble with the
way posting-profiles were managed in <0.90, that he'd like to rework the
feature a bit to make it hopefully more intuitive to discover.  Guessing a
bit as to what form it might take, I envision a per-group default
properties dialog, where one sets the default posting profile, the default
for various filters, etc.  

Another possible option to appear in the group properties would be the
server used to post messages to the group, as that's been another problem
some have had, Pan's choice of posting server when a group occurs on more
than one is somewhat... arbitrary, generally the first server in its list
that carries the group, I believe.  This is as troublesome for some as the
posting profile thing, only it's worse, as changing the profile can be
done if one remembers to do it, while there's no easy way to choose what
server pan uses to post a message.  However, I could just as easily see
this becoming part of the posting profile, since it could be thought of as
part of the posting profile, and once that is retained per group...

Back to post-1.0, Charles has said the order of implementation of
features post 1.0 will depend on what folks most request.  Therefore, your
request for per-group posting profile retention is now added to mine and
has bumped the priority a bit!  =8^)

Meanwhile, while old-pan isn't so good for binary groups due to the memory
requirements, for text groups, it's currently better than new-pan, due to
this and a few other issues with the new PAN. I actually have both
installed, with the old-pan binary renamed to pan.14, keeping it distinct
from the new-pan binary.  I don't use pan.14 that much, only because as a
regular here, I want to stay as familiar as possible with the new PAN, and
therefore use it almost exclusively.  Were it not for that, I'd still be
using 0.14.x for all my text group stuff, until at least the posting
profiles memory thing was resolved.

> 2) Allow a custom font in the message editing window If I'm using the
> built-in message editor, 0.9x used to allow me to choose between the
> monospace or custom font.

No comment on this, other than that I prefer monospace and actually hadn't
noticed that customization was now lacking.

> I actually wrote a patch for this one myself - took all of two lines in
> the user prefs GUI and another two lines added to the posting GUI.  Now
> all I need is "submitting patches to bugzilla for dummies" and I'm all
> set.  I just happened to subscribe minutes before Charles posted his
> "Four Ways..." message (which went right into my permanent Howto folder
> in Evolution) so at least I know where to find Bugzilla.

There's a nice mini-HOTO on patch submission in the Linux kernel docs. 
Obviously, you'll need to adjust somewhat for non-kernel, but in particular
I found its recommendation of using diff -up very helpful.  Before reading
that, I hadn't known whether unified or contextual diffs were preferred
(tho I knew about the three-line thing from the diff manpage), and didn't
realize the benefit of the -p option at all.

${KERNELDIR}/Documentation/SubmittingPatches

Or, if you don't have the Linux kernel sources handy, a quick google on
"submittingpatches linux" works.

> 3) Allow customization of User-Agent header and Message-ID domain

Agreed.  Charles mentioned that a bit of work on custom headers was still
on his todo list for pre-1.0.  That's one of the "minor additions" I
mentioned above.  I wouldn't guess that allowing changes to message-ID
and UserAgent was necessarily on the list, but it might be now!  =8^)
 
> 4) More font choices for different categories Specifically I was looking
> at the message titles window and thinking, "It sure would be nice if
> threads with unread messages were in a completely different font or at
> least a different color".  You can flag different scores in different
> colors in the header pane, why not do the same for other message
> statuses... stati...whatever?

This is a tough one to get right.  One of the reasons new-pan lost the
distinction between new and unread messages that <0.90 pan had was that
Charles judged the additional code bloat not worth it for the limited
additional benefit of the feature.  Some fonts don't have
bold/roman/italic distinctions, and users were sometimes confused when
they saw references to a feature they didn't have, because their font
didn't have those distinctions.  Likewise with colors.  Due to different
color schemes, what works in general may be entirely unworkable for those
users (like me) who have unusual color schemes (I MUCH prefer light text
on a dark background, to the more common dark text on what to me is a
glaring/garish white backaground, and had trouble with the color
defaults for quoted test and URLs in the 0.9x series until Charles made
them customizable again, as the defaults just didn't contrast enough
with my dark background to be easily readable). The only was to guarantee
that the colors work, therefore, is to make them customizable.  Too many
customization options makes the customization dialog confusing for some
users, and again increases code bloat.  /Thankfully/ pan doesn't take GUI
simplification and removal of customization options to the extremes of
much of GNOME, or I'd not be using it (just as I long ago dumped GNOME and
now use KDE as my desktop of choice, with PAN being my only major GTK2
app, tho I'm still using GTK1 based XMMS).  However, Charles has always
been pretty strict about allowing options for options sake, and hasn't
hesitated to take a knife to bloat and features he finds few enough use
that there aren't strenuous objections to their removal.

For that reason, I doubt you'll see much movement on this one.  If it's
important to you, I'd recommend creating your own patches to that effect. 
Once you have them, you are certainly welcome to submit them (#1 in the
four ways... =8^), and for those features submitted as patches, there has
always been a higher chance of inclusion, but even then, it may not
happen, due to Charles' strict anti-bloat policies and previous experience
in the area.

> I think that covers everything I'm losing sleep over.  Is any of that
> stuff already in the development version and I'm just missing it, or was
> it taken out of 0.9x deliberately?

Most was taken out deliberately, but temporarily.  In some cases, it was
to see what features were actually used (the anti-bloat thing I mentioned,
if it's not used, why is it there?) and possibly to adjust the defaults to
something more reasonable, if the only reason the customization was needed
turned out to be due to a poor choice of default.  This is why the early
0.9x series didn't have the options dialog at all. In other cases, it was
simply due to implementation priorities.  It's obvious that things such as
posting profile work much better per-group than globally set, but
per-group state retention (other than message state) simply hasn't been
implemented yet in new-pan, so that feature isn't yet available.



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