walt posted on Sat, 05 Jan 2013 01:20:34 +0000 as excerpted: > If you take a look at (just for example) alt.binaries.photos.original > you'll see quite a few posted jpegs with more than 5000 lines. > > If you click on any of those articles (expecting to view the jpeg) pan > will offer to save the attachment instead of displaying it. > > The reason for this behavior is a test for article size in > header-pane.cc (line 1277) to decide whether the attachment should be > displayed or saved. These days 5000 lines is evidently not big enough > for many posted picture files, so I cheat and edit the file to change > the 5000 to 10000. > > The real problem is that the number is completely arbitrary, of course, > and may increase in the future as digital cameras continue to improve. > > I'm guessing that Charles found the problem annoying and settled for the > existing code as 'good enough'. Just a guess because I wasn't here back > then. But Duncan was :) Any thoughts, Duncan?
I believe one of the big reasons originally was to prevent users on dialup accidentally clicking a huge multi-part post, triggering pan to download the whole thing, just to display it! Popping up the save-as dialog was a hint to especially the dialup user that hey, this post is very possibly bigger than they might want to download on dialup, just out of curiosity or by accident. At least back then, when many WERE on dialup, 5000 lines or so was about the biggest a single-part binary posting tended to be as well, and with even broadband tending to be sub-megabit (a 1.5 Mbit T-1 was SERIOUSLY HIGH SPEED, back then, and download speed or total periodic bandwidth caps were likewise rather smaller!), even broadband users would often have reason to pause at such an obviously multi-part post, as even a 5000- line (especially yencoded) posting could take a minute or two to download and be using up non-trivial bandwidth quota in the process. Of course one solution would be yet another configuration option, but I'm honestly not sure how many would find it useful, especially if that limit is raised to say 10-20 kline (50 kline? 100 kline?) by default. Personally, that's the sort of thing I'd tend to make a config-file-edit setting only, no GUI, as Charles did with say the cache size, which I /did/ actually think should be in the GUI. At least editing the config file is a step easier than patching and rebuilding the sources. But if enough people feel strongly enough about different defaults, then maybe a GUI config option too. Another alternative would be to link that setting to the multi-choice option I proposed for cache-size earlier, such that a user could choose their common usage and have settings such as this and cache size tuned accordingly, between text (10M cache, 1000 line save-as break), still- image (200M cache, 20 kline), mp3 (500M cache, still 20 kline from here up as pan doesn't display them anyway), cd-iso (1-2G cache) dvd-iso (5-10G cache), bluray-iso or multiple ISOs (50G cache), an I'll set my own settings option, with text-boxes for both settings, and whatever other settings might be appropriate as well. But yes, I'd suggest at least raising the default to 10-20 kline and making it a config file setting, with or without a GUI setting to match. -- 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
