[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Pan 13.90 feature hide-n-seek
From: |
Duncan |
Subject: |
Re: [Pan-users] Pan 13.90 feature hide-n-seek |
Date: |
Wed, 12 Mar 2003 01:36:54 -0700 |
User-agent: |
KMail/1.5 |
On Tue 11 Mar 2003 19:23, Johan Ovlinger posted as excerpted below:
> Hi!
>
> A recent upgrade from RH 7.3 to the 8.1 beta (due to hardware upgrade)
> has left my old and trusty 11.4 about as stable as a delusional
> psychotic in a magic-mirror room.
Wow! Scary concept!!
> So I'm forced to run 0.13.90.
U aren't forced to run anything. In fact, if you value stability over the
latest (and possibly stability robbing-est <g>) features, in the 0.13.9x beta
series for 0.14.0, scoring, stable version 0.13.4 would be preferred over the
beta 0.13.90
> In addition to the already mentioned
>
> 1) save-attachment-named-as-article-subject. An improvement over
> 0.11.4 would be to allow the filename to be constructed using
> %s,%a,%d stringsubs. But just plain save as subject would be
> %great.
This has been a requested feature, currently missing, unfortunately.
The general reason some of these features were taken out is two-fold.
One: PAN 0.11.x used Gnome 1, but >=0.12.x used only GTK (2) and a few
libraries, so functionality formerly using the full Gnome were either
dropped, or recoded individually.
One-A: In addition to making a PAN deployment more flexible on *ix, cutting
the Gnome dependencies made porting to MSWormOS far less complex. That's
been done, altho the MSWormOS port isn't considered stable, yet.
Two: Charles is quite keen on keeping bloat to a minimum, it would seem.
Features just for the sake of having them, where they aren't commonly used,
tend to disappear, over time. It can be frustrating if you were one of the
few that used a feature, but it DOES keep PAN lean and mean, and far more
stable and easier to continue maintanance and development than it would be
otherwise.
I'm guessing that specific feature will return at some point. It just isn't
there now. Unfortunately, I don't have any idea when that point might be.
Of course, if you are a coder, a patch might help speed the process
significantly. (hint, hint <g>)
> 2) Reserve a connection for interactive tasks. I'm really suprised
> that this fell by the watside, and thus strongly suspect that I'm
> just not finding it.
This isn't needed any more, in most cases. PAN's task scheduler is far more
dynamic than it was back in 0.11, as the introduction of the gnet library
really made things far more flexible.
The way things work by default now, all connections can and normally are
thrown behind a single task, if said task is a multi-part or batch download.
The scheduler dynamically throws as many connections as necessary (up to the
per server limit) behind the latest task, leaving the previous task for
later. It didn't do this before, so a reserve feature was handy to have.
The one caveat, especially on slow connections, is that the currently active
message segment is completed, by each connection, before your latest task
begins execution. However, since there are up to four such connections to
work with, and as they complete the segment they are on, they switch to the
new task (or one does, if it's just a single message segment that needs d/led
for the new task), this shouldn't be a big problem, except if you are
attempting to d/l huge message segments over a slow dialup connection, which
isn't to practical for such huge segment binary post tasks in the first
place.
> 3) File->Open Attachment (keyboard shortcut O in 0.11.4). An
> improvement over 0.11.4 would be to have this count as an
> interactive task.
AFAICT, that functionality relied on Gnome. This has come up repeatedly, and
is one thing I'd like to get back as well. The suggestions to date have been
to use some sort of image viewer setting, similar to the browser and text
editor settings already there. A variation on that would simply use the
browser to open everything, relying on its handling of mime-types, presumably
with a default MIME type of image/jpeg etc. for non-MIME encoded posts. Even
this would be better than nothing, as from there, one could presumably ask
the browser to open the file in whatever one wanted.
As it stands, the best available work-around is to save-as to your desktop, or
whatever, and open it from there.
--
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin