Re: [Pan-users] number of times one has to press to select multiple groups

[Duncan]

David Chmelik posted on Mon, 22 Jan 2024 06:34:53 -0000 (UTC) as
excerpted:

> On Fri, 22 Dec 2023 23:05:24 -0000 (UTC), Duncan wrote:
> 
>> David Chmelik posted on Sun, 17 Dec 2023 07:32:10 -0000 (UTC) as
>> excerpted:
>> 
>>> Every time I select multiple groups I must press the mouse button
>>> twice, if not three or four times.  Is it set to only accept 'double
>>> "click"' unlike most programs you only have to 'click' once, and is
>>> there a way to set it to the normal 'one "click"'?
>> 
>> Check under Preferences > Mouse .  If those are both set
>> singe-activates,

Seems that's not it...

>> But the mention of three/four times reminds me of the behavior I see
>> when my touchpad is acting up -- IOW a hardware issue...
> 
> I even installed a brand-new mouse but still have same problem.

So not it either...

> Seems might be related to fact that sometimes it takes several minutes
> to load a group, so if I select one, it starts loading it, but then
> maybe I can't select others until finished loading.  Sometimes I just
> select one to read and come back much later.  It'd be good if pan can
> just load what's in the headers windows and not necessarily the entire
> group until you start scrolling, if one even does (not always/often).

Keep in mind threading and sort-order, as well as multi-part (multi-
message) binaries.  Pan can't know what's /in/ the window without loading 
basically the entire group.

In theory (and Charles was considering at one point anyway, sqlite-based) 
the full-group-loading behavior could be worked around with some sort of 
database that sticks around between uses, such that querying for all in 
certain threads and all within a particular subject alphabet range could 
return say subject-threaded approximating a page, but there's at least two 
big problems with that: 1: Finding (and retaining the interest of) good 
database-expert developers to code it up AND maintain the code over 
possibly decades. 2: Get it wrong and you get the infamous database 
corruption issues so many apps have when they go-database-based.  An app 
that regularly crashes and leaves a corrupt database to clean up is 
horrible!

(Take it from someone who switched to the clean text-based claws-mail 
after a decade on kmail... when kmail jumped the akonadi shark and the 
databases had to be regularly rebuilt from the text-based email archives.  
Email has been around awhile and the text-based algorithms to handle it 
are mature and stable.  "It's not rocket science(!!)"; it didn't need 
"databasing" at the expense of stability; and I wasn't going to and did 
not take it when there were other options around, just as surely as I 
wasn't going to and didn't take MS' remote-authorization scheme introduced 
in eXPrivacy when there were other options around.  (Ironically, it was 
thus MS that gave me the final push that I needed to actually jump to 
Linux!))

Meanwhile.... some years ago, before I switched to SSD, as my text-groups 
archives expanded toward a gig of cached messages (dedicated partition so 
it's easy to measure), I found pan taking longer and longer to start up 
(switching groups wasn't a problem, but starting up was).  So I setup an 
autostart entry to load pan when I first started the GUI (KDE/plasma in my 
case).  It could then take 10 minutes or whatever to load cold-cache and 
I'd be fine, doing other stuff when I first started up anyway.  Then I got 
the idea to set up a system service job to start at boot (before the GUI), 
to cat all the files in cache to /dev/null, thereby warming up the in-
memory file cache.  Pan would start faster then, and I basically kept it 
running, restarting it if necessary, to keep the cache from going cold 
again.

I was able to do away with that once I switched to ssd (tho the first 
generation still took some time, but the current ones are fine even at 
SATA-III speeds and modern M2 would be even faster), tho I do still have 
pan set to start at kde startup, but I catch up and then close it, these 
days.

Seems like your group-loading issue is similar but on group load not pan 
startup.

Anyway, you might try middle-clicking (aka third-button, typically middle) 
as opposed to left-clicking, when multi-selecting.  That should select the 
group without loading it, which should also avoid the load-penalty.  (I 
knew that applied to messages (in the header pane) but just tried and it 
seems to apply to groups (group pane) as well, but as I'm not as loaded 
here I can't say for sure.)  See if that lets pan be more responsive with 
the multi-select.

But of course it'll be hard to retrain yourself to the middle-click...

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