#28 end to end testing 4 days ago

Comment by ~mvdan on ~eliasnaur/gio

I think this is resolved, with basic coverage for x11, wayland, and JS.

REPORTED RESOLVED FIXED

#51 self deadlock panic on -target=js when using Window.Invalidate and stdout writing a month ago

Comment by ~mvdan on ~eliasnaur/gio

The code above invalidates all frames, sorry. Here's a program that still repros the panic without burning your CPU: https://play.golang.org/p/SdgNVPfJQJU

Also using the playground because pasting code here will very quickly make the thread enormous.

#51 self deadlock panic on -target=js when using Window.Invalidate and stdout writing a month ago

Comment by ~mvdan on ~eliasnaur/gio

Oh wow, I fucked up that code. Let me try again.

package main

import (
        "fmt"
        "log"

        "gioui.org/app"
        "gioui.org/io/system"
        "gioui.org/op"
)

func main() {
        go func() {
                w := app.NewWindow()
                if err := loop(w); err != nil {
                        log.Fatal(err)
                }
        }()
        app.Main()
}

func loop(w *app.Window) error {
        first := true
        ops := new(op.Ops)
        for {
                e := <-w.Events()
                switch e := e.(type) {
                case system.DestroyEvent:
                        return e.Err
                case system.FrameEvent:
                        ops.Reset()
                        e.Frame(ops)
                        if first {
                                w.Invalidate()
                                fmt.Println("invalidated")
                        }
                }
        }
}

#51 self deadlock panic on -target=js when using Window.Invalidate and stdout writing a month ago

Ticket created by ~mvdan on ~eliasnaur/gio

This is with gio dc7af8fba398233963b420c8fb98b9ec825a0a18.

package main

import ( fmt log

"gioui.org/app"
    "gioui.org/io/system"
    "gioui.org/op"

)

func main() { go func() { w := app.NewWindow() if err := loop(w); err != nil { log.Fatal(err) } }() app.Main() }

func loop(w *app.Window) error { first := true ops := new(op.Ops) for { e := <-w.Events() switch e := e.(type) { case system.DestroyEvent: return e.Err case system.FrameEvent: ops.Reset() e.Frame(ops) if first { w.Invalidate() fmt.Println(invalidated) } } } }

Build and open it with a browser, like:

gogio -target=js -o=out file.go goexec 'http.ListenAndServe(:8080, http.FileServer(http.Dir(out)))'

You'll see a fatal error: self deadlock panic.

#8 X11 support a month ago

Comment by ~mvdan on ~eliasnaur/gio

Thanks so much for your work, ~db47h!

Speaking as a bystander - would it not be worth it to merge what currently works and call it experimental, and then incremental patches can fix the remaining issues? That way, others can test it more easily, and the project won't get a large amount of new lines of code in a single day.

#20 consider another binary name 2 months ago

Comment by ~mvdan on ~eliasnaur/gio

which is very close to the go tool with a slant towards GUI programs.

I'm confused. I assume plain 'go build' for Android produces a binary, while I assume that the current gio produces an APK.

To continue the bikeshedding: goport, gopack, gopherapp.

#20 consider another binary name 2 months ago

Comment by ~mvdan on ~eliasnaur/gio

Note that the same name clashes (such as Roger's issue) happen with 'go install' too, so I don't think this issue is about Linux distro packaging per se.

What's special about your build tool, compared to 'GOOS=android GOARCH=arm64 go build'? Perhaps that's going to help us come to a reasonable name.

#20 consider another binary name 3 months ago

Comment by ~mvdan on ~eliasnaur/gio

I'm afraid gg is far too common, and already taken in the space of Go tools: https://myitcv.io/cmd/gg

I think ggo is a bit too close to 'go', and could confuse some people.

ggio could work. Almost like forcing people to pronounce the tool in one way :)

#28 end to end testing 3 months ago

Ticket created by ~mvdan on ~eliasnaur/gio

I think this project should have proper end-to-end tests to be more stable and maintainable in the long term. That is, automate the checking that the wayland/windows/etc ports actually work properly.

Perhaps I could help by writing the first end-to-end webassembly test. I maintain chromedp, which can be used to drive Chrome via pure Go, so I think that would be a good option for the use case. The test would simply be skipped if Chrome isn't installed.

If that seems like a good idea, I can send a small patch. Ideas are welcome on what kind of features we could test as a start; I was thinking simply an app that changes background color when clicked anywhere. That would be pretty trivial to test via chromedp, issuing a click at a fixed coordinate, and getting the color at the same coordinate.

#1 apps: replace the gophers demo 3 months ago

Comment by ~mvdan on ~eliasnaur/gio

May I suggest something like what you showed at GopherCon UK? For example, a text input and button to add custom labels to a list from top to bottom. This can show:

  • How to use a text input
  • How to use a button
  • How to dynamically add elements to the UI
  • How to lay out elements from top to bottom

I think this covers the basics, and would go further than the existing hello trivial example.`

Bonus points if it scrolls too, but I wonder if that would make the example too complex.