Re: [Pan-users] interface bug (or not?)

[Duncan]

Duncan posted on Wed, 13 Mar 2024 05:56:53 -0000 (UTC) as excerpted:

> In closer-to-plain-English pseudocode:
> 
> First we have a broken-out boolean has_image_type_in_subject (), which
> searches for image-extension strings ( jpg/gif/jpeg/png) in the subject
> line, returning true/false accordingly.
> 
> Then we have the code that's actually interesting to us, gboolean
> on_row_activated_idle, which conditionally activates EITHER
> read-selected-
> article OR save-articles.
> 
> We're interested in those conditions:
> 
> * If there's a valid first-selected-article and it:
> 
> **    Is "smallish"
> **    (defined as having 5000 lines or less)
> **    OR
> **    has a subject line indicating an image
> **    (tested using the broken-out boolean test above)
> 
> ***           Auto-activate read-selected-article
> 
> **    Is "mediumish"
> **    (defined as having 20,000 lines or less)
> **    AND
> **    is a pictures newsgroup
> **    (tests for "pictures" in the newsgroup name)
> 
> ***           Auto-activate read-selected-article
> 
> **    Otherwise (still assuming a valid first-selected-article):
> 
> ***           Auto-activate save-articles
> 
> * Otherwise (no valid first-selected-article):
> 
> **    Just return false
> 
> Meanwhile (#1), the OP's claim was that while visiting...
> 
> gmane.org.unix-heritage.general
> 
> ... he came across an article that didn't "auto-read", instead opening
> the save-article dialog.  He considered that a bug.
> 
> * We know that group name doesn't include "pictures" so the "mediumish"
> test fails regardless of the number of lines.
> 
> * We do NOT know the what the subject line was or how many lines the
> post actually was, but from the described behavior and the logic above
> we can ASSUME the post was BOTH over 5000 lines AND did not trigger the
> image-type-in-subject test.
> 
> * So it fell through to the valid-selected-article:true OTHERWISE
> condition and auto-activated save-articles.

> Meanwhile (#3), I believe the behavior I was describing for multi-part,
> where it doesn't auto-trigger EITHER the auto-save-dialog OR the auto-
> read, must be on that last fall-through condition, no valid article,
> apparently the multi-part, so it doesn't auto-read OR auto-save-dialog,
> just returns false.
> 
> 
> What remains is to discuss whether this behavior can be properly
> described as a bug or not, and whether to tweak (if it's not a bug but
> maybe a test tweak is justified) or change (if it is a bug) the logic
> and behavior above, but this behavior analysis post is long enough so
> that can be a followup.

OK, bug or not?

So the described behavior does have a reason and I'd argue is not a bug -- 
people arguably do not *want* pan to just start downloading arbitrarily 
large attachments, *especially* in what they may reasonably expect to be 
text-only groups, or if someone decides to post say a multi-gig DVD/movie 
binary to what are supposed to be (relatively small) still-image groups.

That code is there to prevent that.

Tho I would argue that expectations have changed over time (connections 
are faster, analog-modem dialup speeds are surely the exception these 
days, and both message and storage size assumptions are accordingly 
larger) and that it's arguably time to consider tweaking the condition 
specifics:

I already mentioned that I locally patch the "smallish" definition to 
double it from under 5000 lines to under 10,000.  Perhaps it's time to 
consider doing that in pan's distributed sources as well?

Altho a 10,000 lines "smallish" is equally arbitrary.  Maybe it should be 
12k, 15k, 20k?

Similarly for "mediumish".  20k seems a bit low for modern usage.  Maybe 
25k, 30k or 50k?  Tho if it's not a still-image that pan can display 
probably auto-save-dialog is better anyway.

Personally I'd propose say 12k smallish, 25k mediumish.  I'd call that 
much more sensible in a modern context altho maybe still on the 
conservative side.  Anyone for say 20k and 50k, or even larger?

I oppose killing the tests entirely and would consider say 50k/100k 
arguably /too/ high, as I doubt most folks would be happy with pan 
unexpectedly and without a dialog downloading whole multi-gig DVD ISO 
sizes, say.

The other possibility would be adding smallish/mediumish sizes to options, 
presumably upping their defaults to at least my proposed 12k/25k in the 
process.  That arguably makes more sense than hard-coding it.  But while I 
can easily patch the hard-codes and could just as easily submit them for 
upstream inclusion after this discussion, options-coding is beyond my 
skill level so that sort of patch would need to be done by someone else.

Meanwhile, anyone want to argue for changes to the in-subject extensions 
test or the in-group-name pictures test?

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