Previously, setHighRefreshRate requires APIs restricted
to Android 30, or higher.
Tested on Android 6.0.1 (released on 2015).
Signed-off-by: inkeliz <inkeliz@inkeliz.com>
When a GPU error occurs forcing the reporting of a DestroyEvent is not
appropriate, because the backend that controls the underlying window
is not aware of the error and will continue to report events.
Replace the crude DestroyEvent by stashing the error and asking the
window nicely to close. The, report the stashed error in the
otherwise regular DestroyEvent.
Hopefully, this second attempt fixes#603.
Fixes: https://todo.sr.ht/~eliasnaur/gio/603
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Change f7aa4b5c8 changed the fullscreen implementation to no longer require
the position and size of the fullscreen window.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
As suggested by ~egonelbre, Decorations should not be the source of truth
for the windows state, because external gestures may also change state.
This breaking change removes Decorations.Perform and exposes Maximized
as a bool which is the user's responsibility to set.
Fixes: https://todo.sr.ht/~eliasnaur/gio/600
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, the window state was explicitly updated whenever
Window.Option was called. However, the system may also change window
state as a result of user gestures, but those changes did not result in
ConfigEvents reflecting them.
Remove the explicit state updates and track them when the system tells
us it has changed.
This is a step towards fixing #600 which require accurate window state
tracking.
References: https://todo.sr.ht/~eliasnaur/gio/600
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There may be a window of time from WM_DESTROY is received to the WM_QUIT
message is delivered by PostQuitMessage. If so, we must not call w.draw.
Fixes: https://todo.sr.ht/~eliasnaur/gio/603
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit zeroes the accumulated scroll distance on the window before invoking the
event delivery code, since the event delivery code is able to call back into the scroll
processing. Prior to this change, the callback could re-processing the scroll delta
while magnifying it by a factor of 10.
Fixes: https://todo.sr.ht/~eliasnaur/gio/599
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit ensures that it is safe to invoke Invalidate() from another goroutine
while a Gio window may be in the process of closing. It can be difficult to prevent
this from happening, as window handles can easily be managed by a type that doesn't
know the exact moment of window close (it might be waiting on the window event loop
to return, but that hasn't happened yet). Without this change, the nil window
driver results in a panic in this situation.
Co-authored-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Custom rendering applications need to be prepared to handle empty view events,
as an empty view event is sent during window shutdown. However, the current
implementation requires applications to write a platform-specific helper
function for each supported platform in order to check whether a received
view event is empty. This commit provides a safe, convenient, cross-platform
method that applications can use to detect this special view event and respond
to it.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit ensures that attempting to perform a system window action prior
to the first call to Event() does not panic. It adopts a similar strategy to
handling Option() prior to the first call to Event(): make a slice of the arguments
and apply them during window initialization.
Fixes: https://todo.sr.ht/~eliasnaur/gio/593
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Up until now, the iOS part has relied on a tool such as gogio to
synthesize a main function. This change adds support for running direcetly
in exe mode, while retaining support for embedded Gio in C programs.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
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>
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>
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>
Elias Naur