Bucharest, Earth

#173 Refactor cmd/gogio flags to avoid globals 2 months ago

Comment by ~schnwalter on ~eliasnaur/gio

I've looked over several cli tools (including go/src/cmd), for now, I've only added an initFlags() function that returns a struct which is passed to newBuildInfo(). The buildInfo contains more information and is now a global variable; this way, I avoided a lot of changes and we can still add more tests.

#173 Refactor cmd/gogio flags to avoid globals 2 months ago

Ticket created by ~schnwalter on ~eliasnaur/gio

Global flags need to be avoided in order to add some tests, I will look into this sometime in the upcoming weeks.

After that, we can revisit this commit:

9bbeb92b cmd/gogio: reuse the test binary to call gogio in the e2e tests

It was created by ~mvdan, where he wrote:

An alternative here would have been to refactor main.go to allow being called directly. However, that would have required a non-trivial refactor, since flag parsing is done via globals. Given that the TestMain method is easy and keeps the main function simple, we've decided to avoid a refactor.

This will allow use to remove the gioui.org dependency from the gogio command tests. The dependency is only required because of the test implementation from that commit, it's not required by gogio at all.

I'm adding some benchmark results here, so that I have some values to compare with the results that I get after the refactoring:

> perflock -governor 90% benchcmd EndToEnd/JS ./gogio.test -test.run=EndToEnd/JS
BenchmarkEndToEnd/JS    1       1646440344 ns/op        617933000 user-ns/op    135779000 sys-ns/op     111808512 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1666625151 ns/op        610389000 user-ns/op    143219000 sys-ns/op     111968256 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1649892298 ns/op        619959000 user-ns/op    140695000 sys-ns/op     112128000 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1650230940 ns/op        574351000 user-ns/op    183671000 sys-ns/op     111894528 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1631252744 ns/op        558702000 user-ns/op    193893000 sys-ns/op     112037888 peak-RSS-bytes

> perflock -governor 90% benchcmd EndToEnd/JS ./gogio.test -test.run=EndToEnd/JS
BenchmarkEndToEnd/JS    1       1654202639 ns/op        615574000 user-ns/op    155924000 sys-ns/op     111624192 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1640356104 ns/op        590132000 user-ns/op    168773000 sys-ns/op     111493120 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1618208652 ns/op        637713000 user-ns/op    133916000 sys-ns/op     112377856 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1648688801 ns/op        588096000 user-ns/op    173820000 sys-ns/op     112218112 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1670452693 ns/op        629662000 user-ns/op    138886000 sys-ns/op     112545792 peak-RSS-bytes

> perflock -governor 90% benchcmd EndToEnd/JS ./gogio.test -test.run=EndToEnd/JS
BenchmarkEndToEnd/JS    1       1653404277 ns/op        620253000 user-ns/op    144668000 sys-ns/op     111652864 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1648087313 ns/op        591378000 user-ns/op    163324000 sys-ns/op     111628288 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1649187530 ns/op        583183000 user-ns/op    169075000 sys-ns/op     111087616 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1633838453 ns/op        580090000 user-ns/op    178996000 sys-ns/op     111861760 peak-RSS-bytes
BenchmarkEndToEnd/JS    1       1681479761 ns/op        589006000 user-ns/op    177368000 sys-ns/op     111624192 peak-RSS-bytes

#170 Improvements for gogio 2 months ago

Comment by ~schnwalter on ~eliasnaur/gio

A better (and portable to iOS) approach for just the status bar color would be to introduce some mechanism to specify it.

I would avoid such an approach, even for simple features such as the status bar color. After that, someone will see that the splash screens needs to have special configuration for these colors. Later, someone will ask for the navigation bar color to be exposed (for android devices with no physical navigation buttons). After that, someone will want the status bar and the navigation bar to be hidden for full-screen applications (video player, games).

These are platform depended features that will be hard to maintain, especially when new platforms will come into play. It will be hard to find people that can develop and test for all platforms, for example: I don't have access to any kind of Windows or Apple device and I won't be able to help with patches that touch those platforms; but I can easily test and provide feedback any kind of Linux/BSD setup.

That's why keeping a minimal toolchain API and with some generic hooks could be one of the best solutions. It will allow people to tie into the build process and make changes at each step. This way, if a platform is not supported, it's easy for a 3rd party to add support for it. Some time ago, we used to have FirefoxOS and Ubuntu Phone, now they are gone, but we have Pinephone and Librem phones. We have Flatpak and Snap, Universal Windows Platform, the Arch AUR an many other platforms that the Gio team should not care about, but a simple "AfterBuild" hook would do wonders for the flexibility of the build process.

If the current code is cleaned up a bit (and I've already done some work on those lines), then anyone can go crazy with their own build systems. Take for example this transformation pipeline for TypeScript projects, it can be very easily adapted to output any kind of library, it was first created for Angular CLI to build Angular libraries, but many people (including me) are using that code to build libraries for various frameworks: Angular, React, Vue.

When it comes to configurations, many people will want a lot of features, and it's impossible to give them what they want. And the current archive dump it's a bit tricky to work with. The afero.FS interface is very small and only depends on the standard os package, if needed it can be replaced at any time. The same is valid for "mage", which uses the go build tags to create these kind of hooks, and if it's needed, it will be trivial to provide a minimalistic replacement.

-- Walter S.

#170 Improvements for gogio 2 months ago

Comment by ~schnwalter on ~eliasnaur/gio

~thetooth, instead of an --export flag, I would prefer to switch the build system to use an Afero based in-memory FS. In this way, various hooks can be provided to expose the FS in various moments: BeforeCompile, AfterCompile, BeforeArchive, AfterArchive.

There would be quite a few advantages to switching to an Afero based FS:

  • it would speedup the builds because the disk would no longer be used to store temporary files.
  • it would speedup testing.
  • it could also be used to provide some sort of partial build cache, to speedup subsequent builds.
  • it could also be used to implement something similar to the Hot Module Replacement from the web-world -- if there's a need for things like that.
  • the Hugo project uses a build system based on a in-memory Afero FS and it has proven to work quite nice for them. But they have a custom FS, which isn't really needed what we have in gogio.
  • because it supports various types of FS: zipFS, tarFS, etc, it could then be used to provide different build outputs for Snap packages, Makeself self-extracting archives , ISOs and what not.

And to implement these hooks, I would use something like Magefile (a go-based Makefile alternative). The mage file containing the hooks would look something like this:

// $ cat magefile.go
// build +mage

package main

func BuildStart(fs afero.Fs) fs afero.Fs, error {} // or BuildStartHook()
func BeforeCompile(fs afero.Fs) fs afero.Fs, error {}
func AfterCompile(fs afero.Fs) fs afero.Fs, error {}
func BeforeArchive(fs afero.Fs) fs afero.Fs, error {} // or BeforePackage()
func AfterArchive(fs afero.Fs) fs afero.Fs, error {} // or AfterPackage()
func BuildFinish(fs afero.Fs) fs afero.Fs, error {}

And, if needed, these hooks can be used to expose a brand new build platform that isn't supported by the Gio core team. Or internal functions could be made replaceable, a user could completely change the archiveAndroid() function. This way, the build system is very flexible and once the API is set in stone, the Gio core team doesn't need to maintain all sort of build scenarios for strange platforms that they can't test.

~eliasnaur, what do you think about this? Would you like me to look more into this and provide some patches? A first one for switching to a in-memory FS

#172 Gio applications throw an error in VirtualBox VMs 2 months ago

Ticket created by ~schnwalter on ~eliasnaur/gio

Out of the box, Gio applications throw an error in VirtualBox Virtual Machines:

no support for OpenGL ES 3 nor EXT_sRGB

I've read in one of the comments that there are plans to provide a sort CPU-only fallback in the future, or something on those lines. But I couldn't find a ticket so I've created this one.

I was able to work around the error by following these three steps:

  1. Install the "Oracle VM VirtualBox Extension Pack" in the host system.
  2. Install the "VirtualBox Guest Additions" in the guest system.
  3. Change the VM's "Graphics Controller" from the default VMSVGA to VBoxSVGA. This can be done in the UI under "Machine » Settings... » Display » Screen" or using the CLI:
    VBoxManage list vms # to get the VM's UUID
    VBoxManage modifyvm «UUID» --graphicscontroller=vboxsvga

Tested on a openSUSE host with a Wayland+Gnome (Debian) guest VM and an X+KDE and X+LXQt (openSUSE) guest VM; though, I'm not sure if the proprietary Extension Pack is required to get this working.

#170 Improvements for gogio 2 months ago

Comment by ~schnwalter on ~eliasnaur/gio

2 & 3 - these need to be more flexible, configurations will need to be possible for sorts of platforms. And all sorts of configurations will be required and they will change from platform to platform.

Also, ~eliasnaur, you'll need to watch out for what features are integrated into the Gio core and exposed behind a custom API or what will be exposed as "native" configuration to the consumer. You'll need to find a way to avoid the problems that the Cordova platform has ran into, where a lot of the basic features required even for simple applications are not in the core and the plugins are basically abandoned, making it hard for anyone to choose the platform. (Thanks for all the hard work.)

P.S. ~inkeliz, watch out for the content behind the status bar, it won't be visible if you set an opaque color. I would prefer to see some sort of API that will expose the height of the status bar and actions bar.