I haven't yet thought things thru properly, but my initial ideas:

• maximized / minimized etc. state should belong to the *Window, not Decorations, so it should come as an argument to it via Update. Otherwise there's a two-way binding issue. It kind of already is via app.Config and Perform, but they can easily go out-of-sync. I guess, it's important to make clear in the code what's the source of truth and what's a cache.
• On WM_SYSCOMMAND the config.Mode needs to be updated, and frame needs an invalidation (probably async is better).
• On WM_SIZE the config.Mode might need updating, but should be already handled by WM_SYSCOMMAND, and frame needs invalidation. In the current implementation the Mode is updated after calling w.update. I'm not quite sure why it's ordered that way.
• It probably could be useful to immediately trigger updating internal state of decorations, to ensure that WM_NCHITTEST returns the correct values. However, it shouldn't break too much if it's delayed until the repaint.

That is done via WM_NCHITTEST; so as long as it is returning correct value from hitTest, then it should be all fine.

Note, I'm not quite sure whether this is sufficient. The maximize and minimize events can be triggered externally by other things as well. For example "alt-space" to open the standard menu and clicking "maximize" triggers the same bug. Similarly, disabling default windowing behavior probably makes things more confusing.

I think the right approach would be to update the decorated state based on what windows thinks it changed to. There's WM_SYSCOMMAND whenever those events are triggered. WM_SIZE probably could be used to detect it as well.

I tried to fix it that way, however didn't quite understand how to propagate that information to decorations.

For questions the mailing list https://lists.sr.ht/~eliasnaur/gio or in Slack #gioui is a better choice.

There are three approaches:

• process your updates before rendering the button, when possible
• use InvalidateCmd to trigger an immediate refresh https://gioui.org/doc/architecture/drawing#animation; when the button title change is internal
• call https://pkg.go.dev/gioui.org/app#Window.Invalidate if the button is changed from an external event.

The second call-stack seems to make things clear.

Also, can you run things with main branch? Based on what I'm seeing in the code, the issue seems still there; but it would be nice to have a stack trace against the main branch.

I'm not sure what the proper fix is either, yet...

CC: ~eliasnaur

Yeah, super weird. Did you try running things with -race?

One thing that might help is to dump the whole internal.Ops. If there's an imbalance then it should be visible from the ops as well.

Oh, maybe there are two operations where the pop order got mixed up?

st1 := push()
st2 := push()
st1.pop()
st2.pop()

Or something similar?

Ok, few ideas in how to debug this.

The usual issue with stack based API-s is that it's easy to make this mistake:

st := example.Push(gtx.Ops)
// ... lots of code and maybe a loop ...
if rand.Intn(10) ==  0 { return }
// ... lots of code and maybe a loop ...
st.Pop()

This kinds of resource problems become more difficult to notice when the Push and Pop call happen at a large distance or different files.

The other case is forgetting the result from push altogether:

example.Push(gtx.Ops)
// ... lots of code and maybe a loop ...
if rand.Intn(10) ==  0 { return }
// ... lots of code and maybe a loop ...
``

Sidenote, while looking at your code, run `go vet` or `staticcheck` on the codebase. I'm not sure whether it's fixed, in the tip, but the `go vet` pre-release mentions (there are few issues in the staticcheck list as well):

./state.go:362:9: State passes lock by value: github.com/jeffwilliams/anvil.CommandHistory contains sync.Mutex ./syntax.go:375:7: the cancel function returned by context.WithDeadline should be called, not discarded, to avoid a context leak

Of course `-race` can help if the code has data-races. Not sure if it has or not.

All that being said, the stack trace does suggest it's happening in material.DecorationsStyle somehow.

For adding print statements, look into `internal/ops/ops.go` and PushOp, PopOp, PushMacro and PopMacro. I would recommend printing the operation and the last few entries in the callstack, then you should be able to track it back to the actual problem. My guess is that it's some sort of early return and the Pop is not being called.

Unfortunately after scanning the Gio code, I wasn't able to notice the issue.

---

Future possible work in case someone wants to try, there are linters that check whether some func has been called e.g. https://github.com/timakin/bodyclose or https://pkg.go.dev/golang.org/x/tools@v0.21.0/go/analysis/passes/lostcancel. Something similar could be made for gio. An easier alternative might be to implement `-tags checkstack` where the `gtx.Ops` and the `Push`/`Pop` either log every single operation or keep track of the callstacks for the calls, such that it's easier to figure out what's the problem.

Removed.

On Sat, May 25, 2024 at 7:29 PM ~eliasnaur outgoing@sr.ht wrote:

CC ~egonelbre.

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/583#event-366594

Removed.

On Sat, May 25, 2024 at 7:29 PM ~eliasnaur outgoing@sr.ht wrote:

CC ~egonelbre.

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/583#event-366594

So, the "linear" part in "linear-gradient" refers to the fact that the gradient happens in a straight line -- not the interpolation space. This is opposed to things like radial-gradient or conic-gradient. It is not as obvious, because Gio only has linear gradient at the moment.

https://gioui.org/doc/architecture/color is a bit clearer on the behaviour. Input is sRGB and blending is in linear color-space. I guess the https://pkg.go.dev/gioui.org/op/paint docs could be clearer on that as well.

If you want to create a sRGB gradient, then there are two approaches. One is you do multiple linear-gradients, with the appropriate distance and colors. Alternatively, you can draw a sufficiently large image of a gradient and use that. I would probably use a 1x256 image of a specific gradient as a starting point.