~eliasnaur

Trackers

~eliasnaur/gio

Last active 5 hours ago

~eliasnaur/scatter

Last active 9 months ago

#166 WASM Keyboard issues 6 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

REPORTED RESOLVED DUPLICATE

#165 Gio cross-compilation for linux, build gioui.org/app/internal/glimpl: cannot load gioui.org/app/internal/glimpl: no Go source files 6 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

I'm sorry, but cross-compiling projects that require Cgo such as Gio require a cross compiler. See for example https://rakyll.org/cross-compilation/. It is usually easier to not cross-compiler and just build your binaries on the target system. So for GOOS=linux you should build on a Linux system.

REPORTED RESOLVED INVALID

#165 Gio cross-compilation for linux, build gioui.org/app/internal/glimpl: cannot load gioui.org/app/internal/glimpl: no Go source files 6 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

I don't see your CGO_ENABLED=1 in your commands. What is your OS and Go version?

What does

$ CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build

say?

#164 Proper modal/z-index/overlay support (proposal) 7 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

Thanks Chris And Jack for the detailed replies. I'm still thinking about the issues, but here's a few comments.

On Tue Oct 13, 2020 at 3:42 AM CEST, ~jackmordaunt wrote:

Thank you everyone for working on this.

A viable overlay API should be able to handle an overlay being constrained by the window bounds.

The thorniest example I have is a right-click popup menu: it must be oriented to avoid the window edges, and resize itself if the window is too small to contain all menu entries.

Correct me if I'm wrong, but both your suggestions involve widgets preparing a CallOp for the overlay content. However, widgets don't have the window bounds nor its position information to orient and size its popup.

Further, Jack's Data indirection (or additional return values) adds complexity to every Widget function even though very few involve overlays.

~eliasnaur

Regarding the multiple returns I agree it adds complexity to the API: not logically, but functionally, since Go will force you to annotate each return type.

However I'm not sure I understand how data indirection adds complexity. It would seem that any widget not using an overlay would leave it alone, and only the specific layouts types would actually care to check for overlay data - thanks to Go's zero values and struct embedding.

By complexitiy I mean the extra fields in Data. It's not much, but somewhat unfortunate every return value needs it.

On the other hand, you could argue Dimensions.Baseline is similarly unfortunate.

It seems to me the right approach is what I think Chris started out with: that overlays are an app-global concern. I glanced at Flutter's Overlay[1], which also seem to be global.

What's missing in Gio to support that approach?

[1] https://api.flutter.dev/flutter/widgets/Overlay- class.html

~eliasnaur

Is there a preference to replicate Flutter's layout design choices in Gio?

No preference. I look at Flutter because that's where Gio's position-less constraints/dimensions layout system is from.

Regarding "needing the window size", would it be as simple as providing the window bounds via layout.Context and letting the overlay handler, eg layout.Flex, simply bounds check each overlay and apply a transform to keep it inside the window.

Yes, but you need both the window dimensions and your own position in relation to the window. Which is not available until after the frame is complete.

#164 Proper modal/z-index/overlay support (proposal) 9 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

Thank you everyone for working on this.

A viable overlay API should be able to handle an overlay being constrained by the window bounds. The thorniest example I have is a right-click popup menu: it must be oriented to avoid the window edges, and resize itself if the window is too small to contain all menu entries.

Correct me if I'm wrong, but both your suggestions involve widgets preparing a CallOp for the overlay content. However, widgets don't have the window bounds nor its position information to orient and size its popup.

Further, Jack's Data indirection (or additional return values) adds complexity to every Widget function even though very few involve overlays.

It seems to me the right approach is what I think Chris started out with: that overlays are an app-global concern. I glanced at Flutter's Overlay[1], which also seem to be global.

What's missing in Gio to support that approach?

[1] https://api.flutter.dev/flutter/widgets/Overlay-class.html

#163 *CommandEvent should not implement ImplementsEvent 15 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

This is intentional, see https://gioui.org/commit/29740ba.

REPORTED RESOLVED BY_DESIGN

#162 Flickering when inputting text into editor that inside horizontal and vertical list layout 20 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

Fixed by https://gioui.org/commit/d2e06d938930. Thank you for the minimal test case.

REPORTED RESOLVED FIXED

#161 Polyline a month ago

Comment by ~eliasnaur on ~eliasnaur/gio

FWIW, I'm working on integrating https://github.com/linebender/piet-gpu (see the "compute" branch). It natively supports stroked paths, including polylines.

#318 Annotations document gone a month ago

Ticket created by ~eliasnaur on ~sircmpwn/git.sr.ht

https://man.sr.ht/git.sr.ht/annotations.md is 404. It's linked from https://drewdevault.com/2019/07/08/Announcing-annotations-for-sourcehut.html.

FWIW, I'm debugging an issue where annotation uploads report a 405 Method not allowed. See the end of

https://builds.sr.ht/~eliasnaur/job/290129

However, I can't remember the content of my secret upload-annotations, nor why it succeeds in spite of a 405.

#154 Android problems: emulators are now x86; example has glitch a month ago

Comment by ~eliasnaur on ~eliasnaur/gio

On Tue Aug 25, 2020 at 14:43, ~ceo_of_programming wrote:

The emulator is Android 10; API 30; x86. The device is a Motorola Condor (Moto-e) with Android 7. Go version is 1.14.4 on Debian amd64.

On the emulator logs, I noticed complains about missing OpenGL support and "Unexpected CPU variant for X86 using defaults: x86". Note the capital "X". It also complained about missing instructions, probably because of the ISA mismatch:

Mismatch between dex2oat instruction set features to use (ISA: X86 Feature string: -ssse3,-sse4.1,-sse4.2,-avx,-avx2,-popcnt) and those from CPP defines (ISA: X86 Feature string: ssse3,-sse4.1,-sse4.2,-avx,-avx2,-popcnt) for the command line:

The SSE instruction family is used for vector processing, so I suspect that might be the reason why OpenGL is not working. The device version does not complain about OpenGL not working.

I don't think the device CPU and instruction set have any influence over OpenGL performance and features, since the GPU is a separate processor.

Logs attached. The emulator log is obnoxiously large, if your text editor can't open it, try emacs or 'cat log.txt | egrep "kitchen"'.

Thanks.

The important log message for the emulator is

org.gioui.kitchen: no support for OpenGL ES 3 nor EXT_sRGB

which indicates that your emulator for some reason haven't enabled OpenGL ES 3. The emulator does support ES 3, so you probably need to tweak a configuration somewhere. I found

https://stackoverflow.com/questions/24874066/does-the-android-emulator-support-opengl-es-3-0


I didn't find interesting log entries for the Moto E glitchy graphics, but given the GPU chip (Adreno 302) was announced in 2013 I'm not surprised graphics rendering doesn't work well. FWIW, Viktor Ogeman and myself are working towards a replacement renderer based on GPU compute which will be able to run on the CPU, side-stepping (buggy/slow) GPUs.

Elias