So I'll give that a shot.

I gave that a shot, and it did work ... and it also got me started down the road to https://lists.sr.ht/~eliasnaur/gio-patches/patches/9145, layout: make List scroll position settable.

Is there any way to programatically scroll a list? ...

I've developed a use-case for this. :)

I think, for me, it'd be sufficient to be able to a) get the index of the top item on the list, and b) set that index as the top item of the same list, at a later time. Basically I display a list, scroll it, display another list, go back to the previous list, and I'd like to display it at the same spot it was before.

... As I wrote that I realized I could conceivably just display a new list on top of the old one, or create a new list object, display it, and then swap the old one back in again.

So I'll give that a shot.

That said, this approach will not apply to every situation (and might not work for me!), so being able to programmatically move or scroll a list will still come in handy eventually.

Gio currently supports only a single top-level window, so exiting the program will close the window. There may be a better way.

I know very little about font sizes and whatnot. My 2-month-old MacBook Pro from work says it's 15.4-inch (2880 x 1800), but then the display setting says its default for the device looks like 1680 x 1050 (a reduction of exactly 7/12 on both dimensions, if you were curious). If I set it to more space it says that looks like 1920 x 1200. I frequently hook up external monitors, one of which is a 4k; I'm away from it right now so I can't tell you want it says about its resolution. I mention all that in case it's useful, but wouldn't be surprised if it's not. :) No worries.

To be honest, I a) don't feel like I know enough to comment intelligently on the issues, even given y'all's detailed explanations, and b) don't really see a question in either of your posts. What are you asking of us? Is there some program to run or setting to set and report back on our impressions of the results? (If so, I'm happy to do that, but again, I don't see that?)

So all that said ... one of an IMGUI's strengths is that it redraws the entire window for each frame. My point being that it seems like none of these values should necessarily be set in stone (i.e. necessarily compile-time constants). Is there any reason you couldn't make any or all of these values tweakable by the user, either the developer or even the end-user? Could you build a UI that shows some sample text and gives you 3-4 sliders and lets you adjust all values and see the results in real-time?

Admittedly, such a thing might be seen as actively user-hostile. (You want me to WHAT?) But, I dunno, maybe it would only be for exceptional circumstances (Yo, I have 20/100 vision, how can you help me? or Yo, I'm running an app on a Jumbo-Tron in a sports stadium, how can you help me? :), or better yet only for a little while, until we (you) got a better idea of what works and what doesn't, what looks good and what doesn't, on the varieties of hardware we all expect to run on.

What do other GUI toolkits do? Maybe this is either a solved problem out there somewhere, or an admittedly UN-solved problem that everybody sucks at.

Never mind, I see this was already mentioned in the Slack channel.

Cool!

Your next mission, should you choose to accept it, is to get Sourcehut to let you set it as a favicon. :)

(And, as an aside, what happens when Teh Spammers (almost) inevitably find the SH mailing lists?)

Note, they already have, we have spam prevention measures in place.

Good to know! (And thanks for the rest of your response, I'm still considering it.)

Amusingly, 90% of spam is stopped dead by the fact that their shitty software can't handle ~ or / in email addresses.

😆

Thanks and thanks! :)

Is there any way to programatically scroll a list? Say if I had two lists but if you scrolled one I wanted the other one to stay in sync? It looks like List.offset records the scroll amount, but of course a user can't read it or write to it, and that's probably not the interface you'd want anyway. (Just curious; I don't have a real use-case for this at the moment.)

So once we get multiple top-level windows (https://todo.sr.ht/~eliasnaur/gio/19), would a Context struct have to have a reference to the window it's in, or is everything any widget needs to know in Config, Ops, and Queue already?

Specific pain points:

• There's no preview or edit on issue/todo comments (like this one). Getting one's formatting right is hit-or-miss.
• Emailed issue updates look like crap in Gmail. I haven't checked in (say) mutt.
• I've yet to figure out how to get mutt/Gmail to not send me my own mailing list submissions twice. Yes, that's all on my end, but on the other hand, it's not a problem with GitHub, and I doubt it'd be one with Gitea.
• Related: I don't see how to get SH to send me a copy of my mailing list submission if I make it directly on the SH website.
• SourceHut is poorly connected. If you know about Gio, finding the mailing list or issues pages is a matter of scrolling down the appropriate part of the README in the Git repo. Or bookmarking them, obviously. A project isn't really a project, it's a loose collection of informally affiliated webpages. (Compare GitHub/Tea where they're all easily discoverable from the front page, and from most other pages.)
• I disagree with the basic assertion that plaintext is better. It has its advantages, which https://useplaintext.email/ lays out, but I find most of the arguments presented there uncompelling. I like real rich text, and I especially like being able to embed images right inline. Or in issues. Or in wiki pages. Or just generally anywhere. (So here I've kind of conflated my objection to plaintext email and to SH in general, I guess.) I think it's hilarious that useplaintext.email itself is not, in fact, in plaintext. Which it lampshades at the end ("But if plaintext is so good, why is this page written in HTML?" "This is a reference document, not an email, you twit.") which argument I also find uncompelling. To me its most compelling argument is that plaintext is more accessible, and it completely discounts its own point while trying to make it.
• Related: Being more-or-less forced to use mutt instead of Gmail is annoying. SH should be able to pull out the text of a multi-part email. (Yes, Gmail has a plain text option, 'tis true. Which it then helpfully remembers for my next email to regular people. Which is also annoying.)
• I find the conflation of a mailing list and a list of patches pretty irritating. I'd prefer they were more separated.

Obviously I don't find any of these issues insurmountable. They're just ... annoying. I still contribute, etc. But nevertheless they're issues that don't arise when random GitHub users want to contribute to random projects hosted on GitHub.

One argument for accepting patches via email is that random people can submit patches without joining anything (GitHub or Gitea or whatever). So ... honestly, is that a huge demographic?

(And, as an aside, what happens when Teh Spammers (almost) inevitably find the SH mailing lists?)

(Here's where I hope for the best and hit Comment, because there's no preview or edit option.)