Tutorials for Gio, the GUI framwork in Go.

Getting the following error when I try to run the Eggtimer Blank window. The window runs briefly and then immediately closes. I can run the hello test from gioui.org perfectly. so don't think it's a missing install.

`panic: runtime error: invalid memory address or nil pointer dereference [signal 0xc0000005 code=0x0 addr=0x10 pc=0xb0b91a]

goroutine 8 [running, locked to thread]: gioui.org/app.(*Window).processEvent(0xc00020a000, {0xc44948, 0xc000206090}, {0xc42158?, 0xc000292000?})`

This is a copypasta from #12 and I'm moving it to an issue because I don't want it to get lost. I think we need to decide what to do, if anything. Until I understand your direction a bit more I feel uncomfortable suggesting which way to go.

The demo at the end of Chapter 1 does not contain an os.Exit(0) line. When the student clicks the window frame's X to exit the app, the window goes away but the process still hangs in the terminal.

Now, you may know that already and it may be intentional for all I know. If it is, I agree with your call, because I'm pretty sure the added complexity to get the os.Exit(0) line into the right place would defeat the goal of keeping this chapter SIMPLE.

BUT, if that IS your reason then my opinion is that you need to do an "information" or "warning" callout at the end of the chapter. The hung process looks bad and makes the project look bad for producing a "failed" demo. Providing just a sentence or two telling the student that "its intentional" and to use ctrl-c to exit the process eliminates this negative "broken" vibe.

Hi, I'm doing these tutorials, they are great.

But I think they are out of date, the Circle has been removed from the package gioui.org/op/clip here: https://github.com/gioui/gio/commit/6534639276d7536b223b56326130f0c68a5e8278

Errors noticed while following the egg timer tutorial.

Thank you for writing this tutorial. I'll have to read it a couple more times for it to fully sink in, but it's a great start for the Gio journey.

First of all thanks for the great tutorial!

I wanted to give something back so I fixed some typos I found while I was following along.

Namely:

Chapter 1: Fix the link to Jeremy Bytes blog Chapter 5: FramEvent -> FrameEvent Chapter 6: margin -> margins Chapter 9: Use f32.Pt + float32 casts

Thanks again for putting your time into this tutorial!

Tutorial: Egg Timer Page: Input Boiltime Link : https://github.com/jonegil/gui-with-gio/blob/main/egg_timer/10_input_boiltime.md

I tried to follow the Chapter 10. There are missed code lines in section 2. The editor widget:

1. There is no clear how boilDuration is initialized. I assume it is extracted number from string boilDurationInput.
2. There are some notes/comments how layouts are done, but there is no code for it.

Hi @jonegil, I noticed an issue in your teleprompter program on my HiDPI screen. Namely, no text is visible. :D

These lines (259-262) are the big problem: https://github.com/jonegil/gui-with-gio/blob/main/teleprompter/code/main.go#L259

You are converting a value measured in pixels into DP with a cast. On my HiDPI screen, this means that if the value was originally 200 Px, it's now 200 Dp which is 400 Px. Setting the margins so high made no space for text to appear between them on my screen, so I saw nothing.

It would be best to convert your codebase to work almost entirely in Dp and Sp. Raw pixel values are only for times when you need to directly invoke Ops (like clipping). Whenever working with layouts, try to use Dp (and Sp for text).

I tried to convert your codebase to doing this for you, but there are a few places that you're using an integer value to modify both text size and positioning of elements, and changing that led to design decisions I didn't want to make for you. I suggest that you redefine all of the values at the top of draw() as one of the unit types and then handle the necessary conversions throughout your layout code. I'm happy to answer any questions you may have about how to do this.

@jonegil let's leave this issue open until I conclude all Chapter 3 edits. Please reply with answers so I know what to do - thanks!

CH3 Q1: Read the following:

io/system - Provides high-level events that are sent from the window. Most important is the system.FrameEvent. It's effectively a list of operations that do one of two things: details how to handle input and describes what to display.

This is confusing. Does it do one thing or two things? Sounds like two. If its two then it doesn't do

one of two things

it does two things. If its one thing then it "details OR describes", not "details AND describes". I'm not sure which one is right.

This PR is a bit different. Let's think about all the kinds of changes that can be made, and then divide them into two groups as follows:

1. Changes that I wrote; we'll call these "substantive" changes;
2. Changes coming from the Markdown linter I am using; we'll call those "linter" changes.

With those definitions in place, I will tell you that I wasn't 100% pleased with the last PR. The quality was fine, but it was a challenge for me to see the substantive changes I made because they were swallowed up in all the noise emanating from the linter changes. Instead of the GitHub merging process showing us the small, "surgical strikes" that my edits usually are, it was deleting entire paragraphs and then replacing them simply because it wanted to replace triple back-ticks with single back-ticks.

I would rather have a much quieter merging experience, wouldn't you?

So, that spawned the idea for this PR. This is an entire PR dedicated solely to the Markdown linter! There is not even one substantive change in this entire PR. If its been changed, the linter did it; I am blameless lol.

Now, be assured that I have still code reviewed each linter change here. If its here then I have agreed to it, albeit sometimes with a smirk. You're going to see the following:

1. Genuine errors being corrected. This includes the code back-tick issue;
2. The linter being very opinionated, even to the point of being a bit ridiculous.

A common example of the second point is when using italics. There are two perfectly valid forms in Markdown for making a word italic: single asterisks and single underscores. Why there needs to be two I don't know, but there are. For no reason — other than having an opinion — this linter changes asterisks to underscores. Does it hurt anything? No. But it certainly makes for a lot of changes when the author preferred asterisks when writing, thus my smirking.

By giving the linter a chance to get its chattiness over with, future PR's will be much quieter with near 100% substantive changes. This PR is an investment towards a quieter, more studious future. — DW

Being consistent with words / abbreviations is recommended.

Markdown (MD) tables should have a dashed line separating "header" columns from "body"; they render better.

MD uses triple backticks ONLY for entire codeblocks (```go). When referencing a keyword like defer, just use single backticks.

The words "intent" and "intention" are REALLY close, almost interchangeable. I've switched to "intent" for the following reasons:

1. As used in the Goal section, the words "intention" and "section" — both ending in "tion" — just don't flow.
2. Intention is usually when a person wants to do something. This tutorial is a more formal thing and "intent" is more formal than familiar.

Link was missing its extension, but magically was still working? LOL

Other "flow" changes, nothing major worth mentioning.

Only got excited (!) in one place, I promise LOL

BTW, I'm Geek Stocks in case you're wondering WTF? (That's "WHO the fuck?") lol

I'm not sure when I'll have time again to proofread so I'm submitting these now. Mostly minor stuff; one broken link. I do intend to get to all of the site as I have time.

One important note for you to consider though. The demo at the end of Chapter 1 does not contain an os.Exit(0) line. When the student clicks the window frame's X to exit the app, the window goes away but the process still hangs in the terminal.

Now, you may know that already and it may be intentional for all I know. If it is, I agree with your call, because I'm pretty sure the added complexity to get the os.Exit(0) line into the right place would defeat the goal of keeping this chapter SIMPLE.

BUT, if that IS your reason then my opinion is that you need to do an "information" or "warning" callout at the end of the chapter. The hung process looks bad and makes the project look bad for producing a "failed" demo. Just a sentence or two telling the student that "its intentional" and just use ctrl-c to exit the process for now. And that you'll fix this issue in Chapter X (I haven't looked but it does get fixed.)

Something to think about. I didn't propose anything because I didn't want to presuppose your intentions.