This way, if the user has a custom winecfg, it can't possibly affect the
tests. I was encountering this as DXVK does not work on virtual Xorg
servers (which we use), and Gio thus failed to render on such a
combination.
>From the numbers below, it can be seen that setting up a new WINEPREFIX
takes roughly five seconds:
$ rm -rf ~/.cache/gio-e2e-wine
$ go test -run EndToEnd/Windows
PASS
ok gioui.org/cmd/gogio 16.369s
$ go test -run EndToEnd/Windows
PASS
ok gioui.org/cmd/gogio 11.810s
A repeated run still has a slow "wine winecfg /?", for some reason. Add
a TODO since I can see it taking a third of the time on my terminal. I
haven't been able to properly investigate why, unfortunately. As far as
I can tell, winecfg is just faster when run with a terminal instead of
an output buffer. They might use isatty on stdout/stderr.
The overall time to run the wine sub-test is increased from ~5s to ~11s,
but it's worth it to make it run everywhere. It looks like there is
plenty of room as per the TODO above, as winecfg seems to mostly do
nothing. We're also not too worried, as all e2e subtests run in
parallel.
Fixes#106.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
This commit updates the implementation of the Enter/Leave pointer
events so that it no longer shares any state with the processing
of pointer presses and grabs. This simplifies the implementation,
though it does leave a certain amount of structural redundancy.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit improves the usefulness of the benchmark by automatically
measuring event processing times with a range of values for the complexity
of the UI.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit fixes a bug which concealed test failures when
the actual event sequence was empty but the expected events
were not.
Additionally, this commit adds the following tests:
- a test for when the active input
area disappears while it is still being "hovered".
- a test for when there are two nested input areas that are
being hovered
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Set the fallback environment variables XDG_CONFIG_HOME and HOME to
make os.UserConfigDir and os.UserHomeDir report useful paths.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
os.UserCacheDir can't work on Android because it doesn't have
access to the Java app context. Gio programs do have access, so set
up UserCacheDir's fallback, the XDG_CACHE_HOME environment variable.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This way, a Gio app's logs can be filtered uniquely, which wasn't
possible before since the tag "gio" would be the same between gio apps.
Since the app ID is supplied at build time, inject it via a variable
with the linker's help. The variable is only used on Android for now,
but that's OK. It might be useful for other platforms or other internal
packages in the future.
Fixes#84.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
It's essentially a copy of go.mod, but with the gioui.org module replaed
with the parent directory. Useful when wanting to try a change in the
root module as part of a gogio invocation or end-to-end test, such as
either of the following:
$ cd cmd; go test -modfile=go.local.mod ./...
$ cd cmd/gogio; go build -modfile=../go.local.mod
Since go.sum can essentially be shared, and since it seems to work with
the go tool, use a symlink. The way the -modfile flag works, if given
foo.mod, it will use the sum file at foo.sum. The only caveat is that
'go mod tidy -modfile=go.mod.local' will try to remove gioui.org lines,
since that module is replaced. So tidy shouldn't be used with -modfile.
In the future, the only upkeep needed for go.local.mod is to update the
external dependencies to mirror changes in go.mod. This is not automated
nor checked by CI, but it could be in the future if it becomes
repetitive or error-prone.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Android apps may want to run Go code independent of the Gio Android Activity.
Expose a Gio.init Java method public for early loading and initialization of
the Go library.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There can only be one JNI_OnLoad callback per JNI library, and the
Gio program may need it for its own purposes.
Gio only used JNI_OnLoad for explicitly registering native methods. Switch
to implicit name based registration and get rid of JNI_OnLoad.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to remove the global JNI_OnLoad constructor, and the
JavaVM singleton is just as easily fetched from a Java JNI callback.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to introduce the Switch widget that re-uses the same
state type as CheckBox. The Bool name covers both uses.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit introduces a naive system for sending events
when a pointer enters or leaves a pointer hit area.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Similar to the previous change to Enum, expose the current state of
the CheckBox. Rename the Checked method to just Update and get rid
of the SetChecked method.
Fixes gio#100
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The Value method both updated the enum value and returned it.
In order to access the current value withoutm, expose the Value
field of the enum and rename the method to Update. As a bonus we
can get rid of the SetValue method as well.
Updates gio#96
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Change gioui.org/commit/0e70fbc1262920a69c60409285795b6bb8701b09
added a note that app.Window.Queue must only be used during the
processing of a FrameEvent. The change was added because a Gio
user took the existence of app.Window.Queue to mean it was always
available.
This change reduces the scope of window Queues by moving it from Window
to FrameEvent, and minimizes the risk of misuse by not offering
Window.Queue at all.
Note that the gioui.org/commit/a937a7653439333b8c6fc30c7a6039b717339766
change moved Window's Frame method (named Update) to FrameEvent for the
same reason.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to reduce the scope of the Window.Queue by moving it
to FrameEvent. As a consequence, Context can no longer rely on a
Queue constant over its lifetime.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The multitude of widget methods on Theme is unnecessary coupling in that all
possible widgets either have to be included in package material, or be
different than 3rd party widgets:
var th *Theme
// Core widget, calling a method on Theme.
th.Button(...).Layout(...)
// 3rd party widget, calling a function taking a Theme.
datepicker.New(th, ...).Layout(...)
Another reason for the Theme methods was to enable a poor man's
theme replacement, so that you could use the same code for
compatible themes. For example,
mat.Button(...).Layout(...)
would not need to change if the type of mat changed, as long as
the new type had a compatible method Button.
However, that point misses the fact that the mat variable had to
be declared somewhere, naming the theme package:
var mat *material.Theme (or, say, *cocoa.Theme)
A better and complete way to replace a theme is to use import renaming.
For example, to replace the material theme with a hypothetical Windows
theme, replace
import theme "gioui.org/widget/material"
with
import theme "github.com/somebody/windows
This change moves all Theme widget methods to be standalone functions,
and renames the widget style types accordingly.
For example, instead of the method
func (t *Theme) Button(...) Button
there is now a function
func Button(t *Theme, ...) ButtonStyle
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There is nothing theme-specific about displaying images and icons,
so move the types from the material package to the generic widget
package.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Double click or tap actions are common in user interfaces and this
commit adds support for it in the gesture package.
ClickEvent has now a new field NumClicks that contains the number of
successive clicks that occurred within 200ms.
Fixes gio#101
Signed-off-by: Pierre.Curto <pierre.curto@gmail.com>
By default, the standard library log package outputs to stderr.
However, stderr is redirected through a pipe to the Android logger,
so recent writes may be not have been sent when os.Exit is called.
The log.Fatal family of functions does just that: write to the log
and call os.Exit.
To ensure all messages are sent, register a synchronized logger at
startup.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Safari's WebGL does not advertise support for EXT_color_buffer_half_float,
but does support rendering to float FBOs.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Safari's WebGL1 implementation (rightly) complains that first-class
array types are not supported as function result types. Define and
use a struct type instead.
While we're here, use const variables instead of functions.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
While launching an app on Android, the hard-coded theme is used for
the color. That color is by default black, and results in a jarring
transition to the actual app background.
The default Gio color is white, so use that for the theme background
as well.
This change will break for "dark mode" programs and similar. A future
improvement would be to reflect the actual app background in the theme.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
According to
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html#//apple_ref/doc/uid/20000738-125024
Cocoa is by default not multithread-safe for programs that use the posix
api for creating threads:
"
For multithreaded applications, Cocoa frameworks use locks and other
forms of internal synchronization to ensure they behave correctly. To
prevent these locks from degrading performance in the single-threaded
case, however, Cocoa does not create them until the application spawns
its first new thread using the NSThread class. If you spawn threads
using only POSIX thread routines, Cocoa does not receive the
notifications it needs to know that your application is now
multithreaded. When that happens, operations involving the Cocoa
frameworks may destabilize or crash your application.
"
That includes Go programs.
The fix, as discovered by Steeve Morin, is to create and launch
an empty NSThread.
Add a package that does that, and use it everywhere Cocoa is used.
Sigh.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The macOS backend doesn't re-create contexts, holding on to the first
created instead. Make sure the GPU leaves the default framebuffer bound,
in case the context is re-used.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Daniel Martí