Track whether requestAnimationCallback has been called when SetAnimating
changes the animated state of the window. Multiple callbacks result in wasteful
redraws.
Without this change, my browser becomes unresponsive when Window.Invalidate
is called every frame. Calling Invalidate every frame is a misuse (InvalidateOp
should be used for animation), but it's nice to have reasonable behaviour.
This change might also fix the issues described in
https://github.com/gioui/gio/pull/7.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Currently, on iOS, the keyboard can block the content since it doesn't
trigger the "resize". Now, the `insets` will provide the size of the
keyboard (on iOS) and scrollbars. It's compatible with the Android (and
desktop), but Chrome automatic resizes the windows, so the `Inset` will
be 0.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Previously, the keyboard is open by default, even without any focus.
Now, the keyboard will remain closed, until `.focus()` is called. That
change also prevents the keyboard from reopening immediately after blur.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
API change. Update your code with gofmt rule and goimports:
gofmt -r "system.ClipboardEvent -> clipboard.Event"
goimports
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Signed-off-by: Elias Naur <mail@eliasnaur.com>
To get the `popstate` we need to create a new entry into
the browser history. Then, Gio will handle the "back" and
"forward" of the page.
In some browsers (Chrome 87/Edge 87): The user must
click inside the window/page at least one time. It will not
work if the user leaves the page (clicking back button)
without interaction with Gio.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
That change mitigates the issue gio#150 and gio#166. The
iOS can only `focus()` as a response to touchstart/click
events. We can't `focus()` at random, without user interaction.
The `w.requestFocus` will try to focus on the next `touchstart`,
which may need some "double click" in some cases. That mitigates
the issue, but doesn't fixes completely, but open the keyboard. (:
I didn't notice any side-effect of that change on Android and on
Windows.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
The context-menu seems useless. The only action available, on the
context-menu is to "Save image": which gives a black image.
I think it's better to remove it. The right-click still work and still
provide `pointer.Event`.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Implement key state for the following platforms:
js, wayland, windows, x11.
Unsupported platforms will continue to function as before, sending
key.Press for all key events.
Signed-off-by: Josiah Niedrauer <josiah@niedrauer.com>
This CL implements the app.Main function as a blocking-forever function
for JS, Wayland, Windows and X11.
This works better for applications that can now programmatically close
windows.
Recently support was added for multiple top-level windows. Add support
for closing those windows.
macOS only; all others stubbed out.
Signed-off-by: Larry Clapp <larry@theclapp.org>
An interface for scaling dp and sp is overkill, at least for all
current uses. Make it a concrete struct type, and rename it to the
shorter and more precise Metric.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Then, make layout.Context.Now a field, copied from FrameEvent.Now.
API change:
gofmt -r 'gtx.Now() -> gtx.Now'
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Function keys don't have a natural rune representation so switch
Event.Name to be a string to fit "F1"-"F12".
Fixes gio#59
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, Gio tries hard to come up with a reasonable UI scale
factor on desktop OSes derived from the physical dimensions and
resolution of connected monitors. Gio also attempts to detect the user
specified system UI scale and apply it.
However, all that is complex and misguided:
- The UI scale should not depend on whatever monitor is connected at
program startup - For multiple monitors, it's unclear which one to base
the scale off. - Applying both a monitor derived scale *and* the user
specified scale is wrong, because the user scale is relative to some
fixed scale, not Gio's derived scale. - With an automatic scale, Gio
does not respect user preference and will not have a similar scale to
other programs on the desktop.
Get rid of the the automatic UI scale detection and rely only on the
user scale.
Updates gio#53
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur