We're moving towards making Window.Event, and in the future, Window.Events
create the window and drive the event loop to completion. In that model,
the other Window methods shouldn't create the window.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
With this change the GPU renderer now properly handles the cases when the stroke width equals the stroke length where the normal vector is the same size as the original vector.
Fixes: https://todo.sr.ht/~eliasnaur/gio/576
Signed-off-by: Walter Werner SCHNEIDER <contact@schnwalter.eu>
According to #565 X11 GPU drivers don't deal well with recreation of
EGL surfaces.
Thanks to Walter Schneider for debugging this issue and coming up with
the original patch.
Fixes: https://todo.sr.ht/~eliasnaur/gio/565
Co-authored-by: Walter Werner SCHNEIDER <contact@schnwalter.eu>
Signed-off-by: Elias Naur <mail@eliasnaur.com>
As reported By Larry Clapp, Wayland would send a ConfigEvent with
every FrameEvent when fallback client side decorations are enabled.
This is because Window would call the driver Option and Perform
methods even when they're empty.
The change applies to every platform, but was only observable on
Wayland.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, a FrameEvent may be delivered after DestroyEvent,
leading to a panic. Destroy the X11 window immediately thus ensuring no
events can be delivered after destroy.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Don't call eventLoop.FlushEvents which in turn applies Options and
executes Run functions before the window is fully initialized.
References: https://todo.sr.ht/~eliasnaur/gio/575
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A single image.Rectangle for the scroll bounds introduced a subtle issue
with zero area rectangles (see #572). To avoid that and similar issues,
split the bounds into two separate one-dimensional ranges.
Fixes: https://todo.sr.ht/~eliasnaur/gio/572
Signed-off-by: Elias Naur <mail@eliasnaur.com>
FBOs and window framebuffers generally have different pixel formats, and
so require separate pipeline configurations.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This picks up some improvements to face splitting and line wrapping within the
text stack.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit fixes our tests to expect some whitespace-handling changes in upstream
go-text.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Using this stable release should ensure user upgrading gio with go get -u do not encouter compilation error
Signed-off-by: Benoit KUGLER <benoit.kugler@gmail.com>
StageEvent served only redundant purposes:
- To detect whether the window has focus. That is covered by
key.FocusEvent.
- To detect whether the window is currently visible. That is covered by
the absence or presence of FrameEvents.
- To detect when the window native handle is valid. That is
covered by ViewEvent.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A uniform type allows convenient nil checks and for future window
backends on platforms other than Linux (which already had ViewEvent
as an interface).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Instead of sending ViewEvents once at construction and once at destruction,
it's better to send them when the underlying NSView changes attachment.
The main advantage is that we're about to move the destruction and
emitting of DestroyEvent to the NSView's dealloc method. However, the
dealloc will not be called if user code has a strong reference to it
through a non-empty ViewEvent. By sending an empty ViewEvent when the
view is detached, well-behaving users will remove the strong reference.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Their absense didn't make a practical difference so far, but we're about
to refactor the macOS event processing loop where the pools do matter.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This is mostly a refactor, but there are two user-visible effects:
- Window.NextEvent may be called even after DestroyEvent is returned.
- Window.Invalidate always wakes up a blocking NextEvent, even when a
FrameEvent cannot be generated.
As a nice side-effect, X11, Wayland and Wasm no longer require separate
goroutines for their window loops.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Now (*widget.Selectable).Update() returns whether the selection changed during
event processing, rather than requiring a separate call to (*widget.Selectable).Events().
The Events() method has been removed as redundant.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit eliminates (*widget.Editor).Events() in favor of making
(*widget.Editor).Update() return events as they are generated in response to
input. This makes the behavior of the editor match the rest of the core widgets.
Callers who previously invoked Events() can now achieve the same thing by using
a loop like this:
for {
ev, ok := editor.Update(gtx)
if !ok {
break
}
// Handle ev
}
This is undeniably more verbose, but it enables more sophisticated event processing.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
The method no longer returns anything, and thus does not actually report
whether any events matched a handler.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Elias Naur