[Pan-users] Re: Re: Connections

[Duncan]

Calin A. Culianu posted
<address@hidden>,
excerpted below,  on Mon, 06 Oct 2003 09:49:14 -0400:

> On Sat, 4 Oct 2003, Duncan wrote:
> 
>> Ronny Hippler posted:
>>
>> > I am using pan under freeBSD and have it set up for a maximum of 3
>> > connections to giganews. When downloading binaries it will only use one
>> > thread at a time.
>>
>> This is a very common misunderstanding of the way PAN, thru gnet, is
>> handling things.  If you have a connection faster than you are allowed to
> 
> Hmm.  In my UI philosophy, if there is a common misunderstanding, perhaps
> the UI could use some tweaking?
> 
> I have long been a believer that the PAN threading/connections status bar
> at the bottom of the main window should be a bit simpler to understand.

I've thought that myself.  However, not being the developer or currently
advanced enough to supply a patch, or even estimate whether it might be
more difficult than is worth it, I've left well enough alone.  My feeling
to this point has been that there are far more "bang for the buck" things
to be worrying about now, especially since this doesn't affect actual
functionality, and things like the missing ability to post attachments
does -- and that's considered a critical core functionality requirement
by many.  Thus, I've been of the opinion that as a purely UI tweaking
issue, it could wait until all "core" functionality was added and working,
and the niggling small stuff necessary before a full 1.0 release was being
worked on, before working on it.  Certainly, either the display should be
changed or at minimum, the as yet unwritten documentation annotated to
reflect the info displayed, before 1.0.  Until then, it's functional, and
there are other core 1.0 functions still missing, so I'd consider it low
priority.

Since it's been brought up, however..  I'd guess that perhaps the easiest
and most direct way to correct the problem would be to have a row of /per/
/connection/ bandwidth status indicators, so one could see what each
connection was doing, rather than just the aggregate, in the status bar. 
Since that info has to be tracked then summed together for the current
display anyway, simply adjusting the display to show up to 8
(thus, two servers of four connections each) two-digit speed readouts,
instead of one far wider display, shouldn't be all that difficult. 
(Getting a bit fancier, display a third digit and a bit more verbosity,
including the KB/s or whatever, as the number of connections decrease,
abbreviate the display as they increase, to avoid taking up the entire
status bar..)

Breaking out what each thread is doing in the task list would be nicer,
info-wise, but may require more rewriting to expose that info in the
worker subroutines so the display routines can work with it.  IOW, I doubt
that info is currently accessible, the reason the task manager hasn't been
rewritten to display it already, after several requests, and expect
exposing it for display would add enough complexity to risk adding
significant bugs in the process.  I'm of the opinion that risk and effort
is probably not worth it just to get the benefit of the additional info in
the display.  However, as I suggested above, there is a way to tackle the
UI misunderstanding issue at hand, in what should be a far less complex
manner, limited tho the additional info displayed would be.

Of course the other and simplest solution would be to simply label the
current display a bit less ambiguously..  Anybody have any reasonable
suggestions, given the space available?  That's been my other sticking
point.. I haven't a proposal for any clearer wording than the current
label.. =:^\

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin