[Pan-users] Re: Thank you for Pan.

[Duncan]

Chris Petersen posted <address@hidden>,
excerpted below,  on Mon, 01 Dec 2003 14:46:29 -0800:

>> Yes, there is: http://bugzilla.gnome.org/show_bug.cgi?id=83973
> 
> So is there any hope on a resolution for this?  I've learned to work
> around it, but it'd be nice to have it fixed.

I've been around on the list for some time, since b4 the switch to gtk+2,
which is where this bug made its appearance.  The below is a bit of the
history and an explanation of why this bug has existed for so long..

Well, as the bugzilla entry shows, it's been there for awhile..
since the move to gtk+2.0.    As implied by the zilla entry, PAN uses a
widget not really designed to handle what it's used for in PAN, rather
than the one that most apps would use for the purpose.  The reason is that
the gtk2 version of the one that SHOULD be used is (or was early on,
anyway) **WAY** to limited in its scaling ability and performance at high
entry counts.  Keep in mind that some groups that PAN must deal with may
have hundreds of thousands or even more than a million overview entries. 
The widget that would ordinarily be used in the overview/header pane
simply wouldn't efficiently scale to that number of entries, so PAN uses a
different one that scales better, but has other limitations, including the
fact that it has been virtually impossible to get BOTH keyboard and mouse
multi-entry selection working correctly at the same time.  Keyboard
multi-selection can be programmed to work in a fairly straightforward way,
but that botches up mouse multi-selection.  The current situation is the
result of fixing mouse multi-selection to work -- at the expense of
causing keyboard multi-selection to break as we've seen with PAN's current
behavior.  That's a hard choice to make, but given that PAN is a graphical
application designed to be used with a mouse, I can see the reasoning in
prioritizing that interface above the keyboard interface, when it's a
choice between the two and fixing one breaks the other, the reasoning I
suppose being that those who really have strenuous objections to using the
mouse, would be using a different environment and probably not even X in
the first place, therefore, would probably be using a different news
client application.  OTOH, PAN is a decent choice for folks at the
opposite extreme, that only use the keyboard to type with, and prefer the 
mouse and point&click as the command interface as much as possible.

At the time, shortly after gtk+2.0 came out, Charles duly filed the proper
bugzilla report on the appropriate gtk+2 widget that wasn't up to scaling
as required for use with PAN.  Since then, if I've followed developments
correctly and kept my widgets straight, PAN has implemented the right one
in the groups list, as widget scaling has improved to the point where the
70k-ish groups on many news servers as entries works reasonably well. 
However, last the issue was discussed, the widget still wasn't up to
scaling to the million-ish entries that some newsgroups on some servers
have, so PAN hasn't been able to switch out the widget used for the
overview pane.  However, I believe that was before gtk+2.1 came out, and
gtk in general has matured quite a bit since then, so it's possible the
"right" widget can actually be switched in, now.

IMO, if performance on the "right" widget is still unacceptable at the
scales PAN needs, perhaps it's time to consider the current widget
situation essentially permanent, and consider a permanent fix for the
problem at hand, as well, even if it involves something more serious in
terms of coding investment than would have been originally acceptable for
what was thought to be a temporary widget itself used as a workaround for
the scaling issue.  Of course, I recognize I'm saying that as a non-coder
that really doesn't have an honest idea of just how much work I AM cutting
out for someone else to do..  <g>  Still, IMO the current behavior should
be addressed b4 PAN goes 1.0, and if the widget situation is beginning to
look permanent..

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