Right now you set the window title at application initialization. I'd like to update it dynamically.

there is no bar at the top and so it cannot be moved, minimized or resized

For what it's worth, in GNOME, at least, it looks like you can alt-drag to move, and alt-right-click to get a menu that has minimize, maximize, move, and resize.

This is on a Virtual Box vm running on a Mac, logged in using the GNOME option (i.e. not the Weston option which just seems to give me a black screen). So a) your mileage might definitely vary, and b) when I say alt-drag what I actually did was cmd-drag, and alt-right-click was actually cmd-two-finger-tap.

This is not to take away from the core issue of this bug report, just to offer something that might help as a workaround. If you knew all of the above already, my apologies.

That does seem to do the trick. Thanks for the quick turnaround!

I sense the DownArrow key during layout, and set the Editor text via SetText, and them Move to len(theText). If the old text was multiple lines and the new text is a single line, then when the editor's Layout is called immediately afterwards (during the same top-level layout), it too tries to process the DownArrow key and panics, because the editor's lines slice is out of date with respect to the underlying editBuffer (Editor.rr).

It seems to fix the problem (or at least hide it) if I hack Editor.processEvent to abort if !e.valid. But that doesn't seem right — it seems like it might lead to too many events being skipped.

But I'm not really sure, so I'm submitting a bug report instead of a patch.

If I queue the SetText to run after the toplevel layout completes, then that also works, because the editor text and the editorBuffer text are still in sync when the editor tries to process the DownArrow key, and then the text is changed after that. That works around the problem, but I think the core of it is still that SetText leaves Editor.lines and Editor.rr out of sync.

Webpack is a packager for web apps, so at a guess you're running this in a browser as webassembly?

First of all, running an http GET in the event loop is a terrible idea, webpack or not. Layout events can happen tens or even hundreds of times per second. Any kind of long running process should be in a separate goroutine.

This is just a guess, but I wouldn't be surprised if the http Client is not implemented in the webassembly code. So quite possibly your log.Fatalf is biting you. That's where I'd look first.

But also take that GET outside of the event loop.

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.