Re: [Pan-users] interface bug (or not?)
On Thu, 14 Mar 2024 00:21:35 - (UTC), Duncan wrote: > Jim Henderson posted on Wed, 13 Mar 2024 21:18:33 - (UTC) as > excerpted: > >> On Wed, 13 Mar 2024 10:53:44 - (UTC), Duncan wrote: >> >>> The other possibility would be adding smallish/mediumish sizes to >>> options >> >> I think "configurable", either globally or per-group > > I hadn't thought of per-group configurable for this. I haven't thought > through whether it'd be particularly useful as opposed to global config, > but at least global config would be good. The only reason I didn't push > configurable more strongly is because I can't do that patch myself, and > I prefer updating the hard-coded values to doing nothing at all, if no > one else coded the patch required to make it configurable. I dislike configuration (which should be changeable) in the code, because it makes it more difficult for non-coding users to make changes that align with their preferences. I can code, but like you, creating a patch for something like this is a patch I'm not able to do without a deeper understanding of the pan code itself, and (maybe not like you - I don't know) I don't have that kind of time. >> and the save dialog should have an option to just view the attachment >> inline as an option. > > That's a really useful idea -- useful enough and obvious enough now that > it's presented, I'm jealous I didn't come up with it! =:^) Sometimes the simplest solutions are the easiest things to overlook. :) >> The behavior as it is is a little confusing, that opening it triggers >> the 'save' dialog, but selecting it in the header pane and pressing >> 'enter' gives a different behavior (ie, showing the image inline). It >> feels like pressing 'n' for the next message should have the same >> behavior as pressing 'enter' after manually selecting the message. > > The current behavior is indeed confusing, agreed there. But I don't see > a way around the two differing behavior cases, because having pan not > display the text (and image if there) by default on "smallish" would be > seriously inconvenient, nor can I see doing away with at least /some/ > sort of "don't just download insanely large posts without a prompt" > behavior. I think it is largely incumbent upon the user to see the size of the post they're reading - there's a "lines" column in the header pane, so if they are looking for it and opt not to skip the large post, that's on them. They can also always cancel it if it's really huge (thus giving them enough time to cancel it). > But your idea to add the view-inline option to the save dialog should > dramatically improve the large-post experience and make it /somewhat/ > less confusing, and if that's combined with making the small/medium > boundaries configurable (or at least modernizing the hard-coded values), > it should go quite some way to improving the overall experience. Thanks! I think it would make pressing 'n' (or 'v' for the previous post) the same as selecting a post and pressing 'enter'. Having that consistency would be a good UI improvement. I would also set the default to "view" rather than "save" so for someone viewing, it's just "enter" "enter" to view the post. > Additionally, a bonus to making the small/medium boundaries configurable > is that there'd then be a natural place in the GUI to document the > differing read/save behavior that's now undocumented, making it less > confusing at least for those that explore config options! =:^) (Option > wording to be determined, but in /theory/ it could help...) That's a good thought. :) -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
Re: [Pan-users] interface bug (or not?)
Dominique Dumont posted on Wed, 13 Mar 2024 19:08:52 +0100 as excerpted: > Please try this out. FWIW I'd ordinarily be right on this as I find it quite interesting, but I still need to adapt my pan live-git ebuild to the pending cmake changes (and not exactly being a build-systems expert I've been putting that off...) so it could be a few days... -- 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
Re: [Pan-users] interface bug (or not?)
Jim Henderson posted on Wed, 13 Mar 2024 21:18:33 - (UTC) as excerpted: > On Wed, 13 Mar 2024 10:53:44 - (UTC), Duncan wrote: > >> The other possibility would be adding smallish/mediumish sizes to >> options > > I think "configurable", either globally or per-group I hadn't thought of per-group configurable for this. I haven't thought through whether it'd be particularly useful as opposed to global config, but at least global config would be good. The only reason I didn't push configurable more strongly is because I can't do that patch myself, and I prefer updating the hard-coded values to doing nothing at all, if no one else coded the patch required to make it configurable. > and the save dialog should have an option to just view the attachment > inline as an option. That's a really useful idea -- useful enough and obvious enough now that it's presented, I'm jealous I didn't come up with it! =:^) > The behavior as it is is a little confusing, that opening it triggers > the 'save' dialog, but selecting it in the header pane and pressing > 'enter' gives a different behavior (ie, showing the image inline). It > feels like pressing 'n' for the next message should have the same > behavior as pressing 'enter' after manually selecting the message. The current behavior is indeed confusing, agreed there. But I don't see a way around the two differing behavior cases, because having pan not display the text (and image if there) by default on "smallish" would be seriously inconvenient, nor can I see doing away with at least /some/ sort of "don't just download insanely large posts without a prompt" behavior. But your idea to add the view-inline option to the save dialog should dramatically improve the large-post experience and make it /somewhat/ less confusing, and if that's combined with making the small/medium boundaries configurable (or at least modernizing the hard-coded values), it should go quite some way to improving the overall experience. Additionally, a bonus to making the small/medium boundaries configurable is that there'd then be a natural place in the GUI to document the differing read/save behavior that's now undocumented, making it less confusing at least for those that explore config options! =:^) (Option wording to be determined, but in /theory/ it could help...) -- 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
Re: [Pan-users] interface bug (or not?)
On Wed, 13 Mar 2024 10:53:44 - (UTC), Duncan wrote: > 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? I think "configurable", either globally or per-group, and the save dialog should have an option to just view the attachment inline as an option. The behavior as it is is a little confusing, that opening it triggers the 'save' dialog, but selecting it in the header pane and pressing 'enter' gives a different behavior (ie, showing the image inline). It feels like pressing 'n' for the next message should have the same behavior as pressing 'enter' after manually selecting the message. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
Re: [Pan-users] interface bug (or not?)
On Wednesday, 13 March 2024 18:25:01 CET Dominique Dumont wrote: > The code you've found does not use MIME in its heuristics. I believe this > code could be improved to take MIME into account. I pushed a possible fix on branch fix-gui-bug [1] (although this patch does not use MIME information. see [2] for explanations) There may be other side effects where it could display article instead of offering the save widget. Please try this out. All the best [1] https://gitlab.gnome.org/GNOME/pan/-/tree/fix-gui-bug?ref_type=heads [2] https://gitlab.gnome.org/GNOME/pan/-/commit/fee591b01e59cea69fbe6a031075d20745d7bb55 ___ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
Re: [Pan-users] interface bug (or not?)
On Wednesday, 13 March 2024 11:53:44 CET Duncan wrote: > 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. Thanks for the analysis In one of the message on povray server, I've found that image are attached using MIME encoding. For instance: Content-Type: image/png; name="Dodecahedron_test_04.png" Content-Disposition: attachment; filename="Dodecahedron_test_04.png" Content-Transfer-Encoding: base64 The code you've found does not use MIME in its heuristics. I believe this code could be improved to take MIME into account. All the best ___ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
Re: [Pan-users] interface bug (or not?)
On Wednesday, 13 March 2024 06:56:53 CET Duncan wrote: > OK, using a keyword (is_smallish) from an old patch I had I grepped (well, > mcedit-searched) the code and found this in header-pane.cc For what it's worth, here's a link to this code: https://gitlab.gnome.org/GNOME/pan/-/blob/master/pan/gui/header-pane.cc?ref_type=heads#L1253 ___ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
Re: [Pan-users] interface bug (or not?)
Duncan posted on Wed, 13 Mar 2024 05:56:53 - (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
Re: [Pan-users] interface bug (or not?)
Jim Henderson posted on Sun, 10 Mar 2024 00:20:07 - (UTC) as
excerpted:
> On Sat, 9 Mar 2024 02:41:42 - (UTC), Duncan wrote:
>
>> AFAIK it's not a size threshold per se, but rather, it happens with a
>> message split into several parts (sub-messages, each sent separately,
>> not multiple parts as in a text part, and html part, maybe other parts,
>> all sent in different sections of the same message, the other meaning
>> of multi-part) for sending. Because this tends to happen with larger
>> messages it does somewhat correspond to size, but the same message sent
>> with a single-part size set low enough to trigger pre-send splitting
>> and sending of those separate parts as different messages will trigger
>> this when pan encounters it, while it won't if the single-part size was
>> set high enough that it was sent as a single un-split message.
>
> I thought this was the case, but it doesn't seem to be.
Sometimes a qualifier like AFAIK is there for a reason. =:^)
I (think I) found the actual code. =:^) See below but
Note that while as a gentooing sysadmin running some packages (including
pan and much of kde-frameworks/plasma/gear) built and updated from live-
git, I've become accustomed to reading git logs and occasionally doing
patches based off them, I'm not a dev and don't have the skills to go much
beyond tweaking patches I come across, thus the "think I" qualifier...
So: read the below code discussion with that big caveat!
> I was mistaken in saying that I access that povray group on gmane - it's
> actually its own DNews server. In the group povray.binaries.images, you
> can see the message at the root of the thread "Reservations" (message ID
> 148096) is a single message with a very long binary attachment.
>
> There's no "part 2" - the message itself is 66,329 lines long, and (if
> you tee the output from nc to a file), you can see that the boundary at
> the top and at the bottom makes a complete file (you have to use
> unix2dos to convert crlf to lf only before using base64 to decode it).
>
> So while this may happen with multipart posts, it also does happen with
> single posts that contain a large encoded binary as well.
OK, using a keyword (is_smallish) from an old patch I had I grepped (well,
mcedit-searched) the code and found this in header-pane.cc (code wraps in
a couple places but line numbers are included and make it obvious where):
1252
1253 namespace
1254 {
1255 bool has_image_type_in_subject (const Article& a)
1256 {
1257 const StringView s (a.subject.to_view());
1258 return s.strstr(".jpg") || s.strstr(".JPG") ||
1259s.strstr(".gif") || s.strstr(".GIF") ||
1260s.strstr(".jpeg") || s.strstr(".JPEG") ||
1261s.strstr(".png") || s.strstr(".PNG");
1262 }
1263
1264 gboolean on_row_activated_idle (gpointer pane_g)
1265 {
1266 HeaderPane * pane (static_cast(pane_g));
1267 const Article * a (pane->get_first_selected_article());
1268 if (a) {
1269 const size_t lines = a->get_line_count();
1270 const bool is_smallish = lines <= 5000;
1271 const bool is_mediumish = lines <= 2;
1272 const bool image_subject = has_image_type_in_subject (*a);
1273 const bool is_pictures_newsgroup = pane-
>get_group().to_view().strstr("pictures")!=nullptr;
1274 if (is_smallish || image_subject)
1275 pane->_action_manager.activate_action ("read-selected-
article");
1276 else if (is_mediumish && is_pictures_newsgroup)
1277 pane->_action_manager.activate_action ("read-selected-
article");
1278 else
1279 pane->_action_manager.activate_action ("save-articles");
1280 }
1281 return false;
1282 }
1283 }
1284
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. (I'm working with/around pan's
wrapping code here, while trying to avoid triggering its quote-
recognition, thus the *** style logic indention.):
* 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):
**
Re: [Pan-users] interface bug
On Sun, 10 Mar 2024 00:20:07 - (UTC), Jim Henderson wrote: > it's actually its own DNews server. That server is news.povray.org - sorry, I thought I included that in my reply. :) -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
Re: [Pan-users] interface bug
On Sat, 9 Mar 2024 02:41:42 - (UTC), Duncan wrote: > AFAIK it's not a size threshold per se, but rather, it happens with a > message split into several parts (sub-messages, each sent separately, > not multiple parts as in a text part, and html part, maybe other parts, > all sent in different sections of the same message, the other meaning of > multi-part) for sending. Because this tends to happen with larger > messages it does somewhat correspond to size, but the same message sent > with a single-part size set low enough to trigger pre-send splitting and > sending of those separate parts as different messages will trigger this > when pan encounters it, while it won't if the single-part size was set > high enough that it was sent as a single un-split message. I thought this was the case, but it doesn't seem to be. I was mistaken in saying that I access that povray group on gmane - it's actually its own DNews server. In the group povray.binaries.images, you can see the message at the root of the thread "Reservations" (message ID 148096) is a single message with a very long binary attachment. There's no "part 2" - the message itself is 66,329 lines long, and (if you tee the output from nc to a file), you can see that the boundary at the top and at the bottom makes a complete file (you have to use unix2dos to convert crlf to lf only before using base64 to decode it). So while this may happen with multipart posts, it also does happen with single posts that contain a large encoded binary as well. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
Re: [Pan-users] interface bug
Jim Henderson posted on Fri, 8 Mar 2024 06:51:23 - (UTC) as excerpted: > On Thu, 7 Mar 2024 21:09:37 -0800, dchmelik-Re5JQEeQqe8AvxtiuMwx3w > wrote: > >> Earlier today I was reading usenet & gmane but suddenly when I went to >> gmane.org.unix-heritage.general and selected an article to read, it no >> longer loads it rather than doing a popup asking to save articles. I >> even exited, and removed preferences.xml (always seems to get corrupted >> and cause bugs/crashes) and restarted and went back to select article. >> It did the same thing. Apparently the article contains a .png that >> when I pressed right mouse button and selected 'read article' loaded >> that. Afterwards I could read plain-text articles fine. > > I've observed this behavior as well - you get the save dialog if you > just open it by using "next" to move through posts, but if you hit > escape and then hit enter, it'll load the image in the message pane. > > I see this on gmane on in povray.binaries.images quite regularly. > There's a size threshold that it hits before it asks to save rather than > viewing by default. AFAIK it's not a size threshold per se, but rather, it happens with a message split into several parts (sub-messages, each sent separately, not multiple parts as in a text part, and html part, maybe other parts, all sent in different sections of the same message, the other meaning of multi-part) for sending. Because this tends to happen with larger messages it does somewhat correspond to size, but the same message sent with a single-part size set low enough to trigger pre-send splitting and sending of those separate parts as different messages will trigger this when pan encounters it, while it won't if the single-part size was set high enough that it was sent as a single un-split message. IOW, basically it's pan saying "Hey, there's multiple parts here to deal with, do you want me to assemble them and save as I might process a binary, or do you want to cancel that process?"... which then allows you to hit enter or whatever you have the read-message shortcut set to, to assemble the message parts manually and display it as if it were a single- part message (which you can then of course trigger save on if you want, just as you could on a normal single-part message). Meanwhile, if you attach one or more things to a single message (which then appear in the raw message as multiple sections), which then exceeds the size of a single part so it is pre-split before sending, then you have both meanings of multi-part applying to the same message and it can be REALLY confusing. ... Which of course is usually what happens if a person posts a message with both text and a binary attachment (thus multi-part in the one sense) big enough to trigger a split (thus also multi-part in the other sense)... It's no wonder people get confused... or that I encounter such difficulty trying to describe the result! =:^) Oh, and if you're curious where pan's split-size setting is for the posts you send, check preferences, upload tab. =:^) (These days it's not such a big deal, but consider people on dialup who might have spent an hour or longer on a single message only to have it error out. Better to have the sizes small enough so you can get each part in say 5 minutes with reassembly after download, perhaps redownloading just the one bad part or asking for someone who got it correctly to repost it. Actually, that sort of splitting made reposting just a single part difficult, so other sorts of pre-post-splitting eventually took its place and good posters would use them and set the posting client's auto-split size a bit larger so the posting client would never actually do a split like this, but the option remains and autosplitting still occurs if the split size is low enough to trigger it, which it can be if someone tries to attach too much and doesn't use some other form of pre-splitting.) -- 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
Re: [Pan-users] interface bug
On Thu, 7 Mar 2024 21:09:37 -0800, dchmelik-Re5JQEeQqe8AvxtiuMwx3w wrote: > Earlier today I was reading usenet & gmane but suddenly when I went to > gmane.org.unix-heritage.general and selected an article to read, it no > longer loads it rather than doing a popup asking to save articles. I > even exited, and removed preferences.xml (always seems to get corrupted > and cause bugs/crashes) and restarted and went back to select article. > It did the same thing. Apparently the article contains a .png that when > I pressed right mouse button and selected 'read article' loaded that. > Afterwards I could read plain-text articles fine. I've observed this behavior as well - you get the save dialog if you just open it by using "next" to move through posts, but if you hit escape and then hit enter, it'll load the image in the message pane. I see this on gmane on in povray.binaries.images quite regularly. There's a size threshold that it hits before it asks to save rather than viewing by default. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
