Comment by ~inkeliz on ~eliasnaur/gio
I tried to add
w.w.Event(pointer.Event{Type: pointer.Cancel})
tovisibilitychange
. Thevisibilitychange
is triggered, I receive theStageEvents
, but thepointer.Cancel
seems to be ignored, in somehow. It's received in thepointer.Push
, but doesn't remove the last click.I don't know, weird. 😣
Comment by ~inkeliz on ~eliasnaur/gio
That bug is annoying if you are open another window (say
window.open("https://google.com"
) when you click. Then, the mouse gets trapped because it triggers the button every time you return to Gio ( since the mouse is never released).The workaround is to track the
pointer.Released
instead ofpointer.Press
.
Ticket created by ~inkeliz on ~eliasnaur/gio
I notice some bugs while testing on WASM and Windows (on Windows it's veeeeeery rare). On Android it might be possible to reproduce, but I didn't try, yet.
The issue is that Gio doens't send a
pointer.Release
if the mouse is never released. The mouse can be "never released" because switch the Window.
Easy way to reproduce the problem:
- Open two tabs on Chrome.
- In one tab (the first one) open the Gio app which contain some button (the Kitchen demo).
- Press some button and keep pressed.
- While your mouse still pressed, hit "CTRL + 2". It will switch to another tab (the second one).
- Leave your mouse in that second tab.
- Return to the Gio app.
- Click anywhere in the Gio app (outside of the button).
Result: Even clicking outside of the button, the button will be triggered.
On Windows it's more difficult to reproduce, it happens once and I think it was related to that problem.
Maybe, once the "focus is lost" (system.StageEvent), the pointer must be reseted in somehow?! But the pointer.Push() doesn't have access to the current Stage of the app. 😶
Comment by ~inkeliz on ~eliasnaur/gio
Reverting that patch also makes the frame generates everytime, without
op.Invalidate
. :S
Comment by ~inkeliz on ~eliasnaur/gio
Reverting that patch fixes the issue. 🥳
Comment by ~inkeliz on ~eliasnaur/gio
The change is cc63a3aeb7320d8859fee009a970fbed7d1d3187.
Ticket created by ~inkeliz on ~eliasnaur/gio
Seems that have one bug on current Editor (and maybe other widgets). If the user is using Touch (pointer.Touch), and tries to scroll the text in the Editor, it will make impossible to click in the Editor again.
As a result, the user can't move the carret and can't focus on the Editor (if the focus is lost).
The step-by-step to reproduce the problem is:
- Run the Kitchen Example on mobile device (or emulating; i.e https://gioui.org/files/wasm/kitchen/index.html).
- Touch on the "Hint Editor" (single line editor).
- Type some "long" word in the Editor.
- Touch on the end of the text and, while pressing, move the fingers close to the start of the text.
- Touch again in any part of the text: It will not work anymore, the Editor is dead. :|
I'm trying to fix that, but I'm out of luck. :|
On desktop that problem doesn't happen.
Comment by ~inkeliz on ~eliasnaur/gio
Far I know, you need OpenGL ES 3 (with sRGB and some floating-point support). Maybe it's related to https://todo.sr.ht/~eliasnaur/gio/172.
Comment by ~inkeliz on ~eliasnaur/gio
Can you sketch a use-case where you need the ordering you mention? I think we may be able to change op.Defer to run nested defers immediately after their containing defers.
In my use case, my design is the following:
- Header
- Body
The
Body
almost always use somelayout.List
to be able to scroll. I want to "Header" be always visible, so I use theop.Defer
forHeader
and I render it after everything (usingop.Offset
andop.Stack
) to enforce the order. So, in order of rendering it is: 1. Body; 2. Header.If the "Body" contains some "Modal", it works. The "Modal"/"Pop-Up" will overlay any "Body" content, but doesn't overlay the "Header". That is what I expect and what I get. Fine.
However. One of my "Editor" have another
op.Defer
. So, if I put one "Editor" inside the "Modal" of the "Body" (in the end: Body -> Modal -> Editor), it breaks everything. The Editor can overlay the Header, since it's oneop.Defer
inside another (the modal).The only way to fix that, is change the Header to 2x (or 3x)
op.Defer
. I'll try to make some in-code example of it.
Comment by ~inkeliz on ~eliasnaur/gio
I'm playing the
op.Defer
for while, I already notice some problems while using it. Consider the following code (https://play.golang.org/p/Lq2Kk6ZL7-J):// First Macro - Black op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) { clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops) paint.Fill(gtx.Ops, color.NRGBA{0, 0, 0, 255}) })) // Second Macro - Red op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) { clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops) paint.Fill(gtx.Ops, color.NRGBA{255, 0, 0, 255}) // Inner Macro - Blue op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) { clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops) paint.Fill(gtx.Ops, color.NRGBA{0, 0, 255, 255}) })) })) // Third Macro - Green op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) { clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops) paint.Fill(gtx.Ops, color.NRGBA{0, 255, 0, 255}) }))
This code have multiples
op.Defer
, all of them changes the color of the "screen". I think that the result would be "Green", since it's the lastop.Defer
in the code. However, the result is "Blue", which is theop.Defer
inside anotherop.Defer
.That behavior is really dificult to handle. The only way to fix that is doing:
op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) { op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) { op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) { clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops) paint.Fill(gtx.Ops, color.NRGBA{0, 255, 0, 255}) })) })) }))
That code will enforce that the "Green" have a "deeper-op.Defer" than the "Blue". In the end: for every nested
op.Defer
I need to create a newop.Defer
to make the last-one longer than any other.