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

Standalone demo in https://lists.sr.ht/~eliasnaur/gio/<20190830140250.GA33016%40larrymbp14>/raw .

See thread for context.

On Fri, Aug 30, 2019 at 9:42 AM ~eliasnaur outgoing@sr.ht wrote:

I propose a layout.Context type for aggregating the common arguments, similar to the Context type from Gregory Pomerantz' giowrap experiment. The simplest implementation is the straightforward struct:

type Context struct {
    Config ui.Config
    Ops    *ui.Ops
    Queue  input.Queue
}

Reducing the above signatures to:

func (e *Editor) Layout(c layout.Context, cs layout.Constraints) layout.Dimensions
func (l *List) Init(c layout.Context, cs Constraints, len int)

I decided against including the constraints to Context because constraints change all the time during layout, while the other values almost never change.

I'm in favor.

Is there any reason to not just store either the Context, or its component members, right in a widget (Editor, List, etc)? You said yourself they almost never change. Ops is already a pointer, and ui.Config and input.Queue are both interfaces, both of which are typically (solely?) implemented by methods on pointers, so you could change the thing pointed to and everyone using it would see the updates.

(This could be a horrible idea. Just asking.)

As for this type itself, seems like it could be confused with a context.Context? Maybe call it a GContext (G for Gio, natch, or gui, or graphics) or WContext (W for Window). Again, just a thought. Arguably the layout. prefix should be enough.

In any case, if this is adopted, please stay away from calling variables of type layout.Context ctx, since I think that definitely would be confused with context.Context! Maybe gctx there.

-- L

I tried pasting into an Editor widget with Cmd-V (on a Mac). it didn't work. I also see no way to select text and copy it.