Jim Henderson posted on Wed, 13 Mar 2024 21:18:33 -0000 (UTC) as excerpted:
> On Wed, 13 Mar 2024 10:53:44 -0000 (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
