Multiple Wayland windows are now separate, except for the global callback
reference map. Use a sync.Map to support multiple concurrent windows.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The callbackMap is used to look up Go references in event callbacks. Instead
of registering one entry for each possible callback type, use a single
handle for each Go reference.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
material.Clickable is useful for adding a click response to any widget
or area.
Rename widget.Button to widget.Clickable to reflect the wider use
spectrum.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, the widget.Button.Layout method assumed the caller had set
up the pointer hit area before. Further, the very common rectangular hit
areas needed both an AreaOp and a widget.Button.Layout call.
Make widget.Button less subtle and more useful by setting up a
pointer hit area given by the incoming minimum constraints.
Drop a pointer.AreaOp made redundant by the change.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Setting a ColorOp before calling a widget function is too subtle.
Let the widget manage its color instead.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
First, use wineboot instead of winecfg to set up the WINEPREFIX. It's
the right tool for it.
Second, when initialising WINEPREFIX, use output pipes instead of
CombinedOutput. The latter will wait for *all* output to be copied to a
buffer, including the output from grandchildren processes. Since wine
starts wineserver automatically, and wineserver lingers for three
seconds by default, this is bad. We would waste three seconds waiting
for wineserver doing nothing, and then the next wine call (to start the
app) would need to start wineserver all over.
Instead, with pipes we can get cmd.Run to only wait for the parent
process to finish. wineserver stays running but we don't care. And, when
we start the gio app, we very likely reuse the same wineserver process.
Third, disable wine-gecko and wine-mono. This ensures we don't get stuck
if they're not installed, and speeds up wineboot by avoiding work we
don't need.
The time to set up WINEPREFIX goes down form ~6s to ~1s, and the overall
subtest run-time goes down from ~10s to ~3s.
Finally, copiously document all of the precious data I've gathered above
after hours of debugging.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Fix a long-standing TODO: instead of each sub-test handling its own
output separately, just make each expose its output via an io.Reader.
Then, the shared driverBase code can tell if any of the lines contain
the magic "gio frame ready" string.
Reduces the amount of code a bit, but most importantly, it keeps the "is
a frame ready?" logic in a single place.
In the future, this also enables us to do more with all the e2e test app
output consistently. For example, we might want to add a -debug flag to
always log output lines as they happen.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
A simple 'go test -modfile=<path>' won't work properly for the
end-to-end tests, since they run 'go build' under the hood as well.
To properly propagate the flag, we need to use GOFLAGS. Since -modfile
is always relative to the current directory, we can't use it to test
many packages at once, nor can we use it via 'go test ./gogio'.
While at it, document this distinction in go.local.mod to prevent others
getting confused like I did.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
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>
Elias Naur