I can't say why this is happening for you. The method ~inkeliz suggests above works reliably for me. I do know that writing to os.Stderr or os.Stdout can also trigger that window, does your application do that (directly or indirectly with fmt or log)?

I can't test right now, but I guess it should be -H=windowgui, https://github.com/gioui/gio-cmd/blob/main/gogio/windowsbuild.go#L214.

You have two options:

1. Using go build: adds the flags -ldflags=-H=windowsgui. So, compile using go build -ldflags="-H=windowsgui" ..

2. Using go run gioui.org/cmd/gogio -target windows .. That will use gogio, which sets the icon and also hides the console.

I think that was mentioned at Community Call. But, since Gio uses "Immediate Mode" such information is "not reliable", far I remember. I'm using similar construction for List, in order to get the current position of the element in the list. :S

You are right. I forgot about such refs. I thought that such event.Tags was serialized together (in []byte), since it's only used as "id".

Why not store every high-level event (click, right-click etc...) inside the widget, and its update method will just append to that? The Clicked(gtx), RightClicked(gtx) can return whatever is first in the internal slice of events?

That is the point. However, to store you need to update the state. But, updating the state can cause the next read of gtx.Events to have another behavior.

Crazy idea: can we make event.Tag an *[]event.Event and directly fill that slice from the router? That way, there's no need for gtx.Events, and thus no need for gtx. There's still a need to check/call an internal update, but the external API is nicer.

I suggest something similar on Slack: https://gophers.slack.com/archives/CM87SNCGM/p1666455976528169 . The only issue is: *[]event.Event can get dereferenced by GC, IIRC.

Well, that approach may work, but I think it may not work on all cases. I think it has two issues:

State-Widgets: Consider something like btn.Clicked(gtx)/btn.RightClicked(gtx), the btn may store Entered bool or PressedSince time.Time (to be equivalent of right-click on mobile devices)... Those fields will reset when pointer.Release is received. So, the next call to btn.Clicked(gtx) will not have the same behavior of the previous one, even on the same frame.

Recalculation: I think it's better to update everything once, than multiple times. If you have some "complex" widget, or many of them, sounds more efficient to update it only once per frame. Of course, that varies depending on the use-case and the widget itself.

---

My idea is to "hide" the Update, so you don't need to call Update directly. I think the requirement of call Update sounds annoying, because you must be sure that Update was called earlier.

That issue is duplicated, but I can't find the duplicate on SourceHut.

As anyone knows, the Layout is also responsible for updating the widget contents. That may introduce some delays, as reported by Dominik Honnef on Slack (https://gophers.slack.com/archives/CM87SNCGM/p1665506913059919 )

---

Currently, I'm using something similar to what I will describe on my app. Also, in an older version of Gio, it was possible to get the version from the Ops which was great to compare "if it is the same frame".

My idea is to change methods such as Clicked to Clicked(gtx layout.Context) and the same for all equivalent functions.

Internally, the Clicked() will call update IF it's another frame, and will act like no-op IF it's the same frame.

In general:

if btn.Hovered(gtx) { // First call to btn, on the frame: Update the state and return the update-state

}

if btn.Clicked(gtx) { // Second call, same frame, will get the .clicked, but will not update it (the gtx.Event() is already deleted).
}

It's possible to see one example on https://go.dev/play/p/a02Ni-jLT00.

Using the current Gio-core implementation, that will have another behavior (https://gophers.slack.com/files/U03S24JEP/F045MFQ39JB/hover-2022-10-11_19.32.12.webm ).

In general:

func (b *Clickable) update(gtx layout.Context) {
	if b.lastFrame == gtx.Now {
		return
	}
        b.lastFrame = gtx.Now

       /// ...... the code that processes the event
}
```

Then, every method (such as `Clicked(gtx)` or `Hovered(gtx)) will first call `update` internally.

That issue persists, not exactly. I think Gio is ignoring some events. Opening https://gioui.org/files/wasm/kitchen/index.html on iOS, and try to modify or scroll the "multi-line input", or slide the slider (...), sometimes doesn't work and freezes the element/widget.

It doesn't crashes the page, but makes many components unresponsive.

I forgot to mention this issue on https://github.com/gioui/gio/commit/83cb3835232bbabb1f7f96c473bcca30ae83c46c, but that is fixed now.