Last active 2 days ago


Last active 9 months ago

#168 Gio blocks changing language keyboard via Alt+Shift on Win10. 2 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

I did discover a possible source of missing system message. Please try again with https://gioui.org/commit/3740f891710213949 applied.

#168 Gio blocks changing language keyboard via Alt+Shift on Win10. 2 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

I can't reproduce the problem. When I press Alt+Shift the language selector pops up, both for the kitchen sample as well as when other Windows programs are focused. I still have to choose a language with the mouse, though.

#168 Gio blocks changing language keyboard via Alt+Shift on Win10. 2 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

What's the impact of this issue? Windows usually hangs when showing menu etc. See for example https://stackoverflow.com/questions/11623085/pressing-alt-hangs-the-application

#116 Samsung Default Keyboard cannot type in Android Gio Editor Widget 3 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

On Mon Oct 26, 2020 at 15:02, ~whereswaldon wrote:

Just wanted to drop by with an update. I experimented with this over the weekend, and I found an approach that seems promising on the Android side. I don't have a full PoC yet, but I hope to soon.

I'm essence, we can gain a ton of text input features by creating an invisible EditText widget for each gio window and subscribing to updates to it's state. That saves us from needing to implement an entire editor in gio core, and we can instead focus on translating the changes to that editor's state into events.

It's a good idea, but unlike in the browser I don't think you need the heavy-handed EditText widget hack. There's Editable[0] and an implementation[1] in the standard library that you can re-use for the heavy work of interfacing with the input method. I believe those are what Flutter uses and what I'd start with.

[0] https://developer.android.com/reference/android/text/Editable [1] https://developer.android.com/reference/android/text/SpannableStringBuilder


#167 Filled regions disappear when transformed 3 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

On Sat Oct 24, 2020 at 5:41 PM CEST, ~whereswaldon wrote:

Okay, yeah. I was able to confirm that using a large-but-not-infinite value works. This variation of paint.Fill doesn't have the problem:

// Fill paints an infinitely large plane with the provided 
color. It
// is intended to be used with a clip.Op already in place to 
// the painted area. Use FillShape unless you need to paint 
// times within the same clip.Op.
func Fill(ops *op.Ops, c 
color.RGBA) {
	defer op.Push(ops).Pop()
	ColorOp{Color: c}.Add(ops)
inf := float32(1000000000)
		Rect: f32.Rectangle{
f32.Pt(-inf, -inf),
			Max: f32.Pt(+inf, +inf),

That being said, I'm not sure that the proper fix is. I worry that, no matter what value we choose, it will break someone's zoom animation at some scale in a future UI. ~eliasnaur do you have any recommendations?

Yeah, I suspected that infinities wouldn't play well with transform. Let's just use a large number for now, say 1e9.


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

Comment by ~eliasnaur on ~eliasnaur/gio

I still haven't thought all this through nor closely read all your posts. So I'm sorry if the below have been discussed:

On Thu Oct 22, 2020 at 10:36, ~jackmordaunt wrote:

What I think we should avoid, and this is just my intuition so it could be misguided, is the z-index as seen in CSS. The reason being: each widget would have to know (guess) the z-index it should render the overlay at. This creates really tricky data dependencies. This is why in CSS you often see z-index of 999999 just to ensure it sits on top - because the UI programmer doesn't want to juggle each and every z-indexed element.

I see the problem with absolute Z values, but it seems to me the layering issue of popups is the easiest to solve with relative, implicit Z values.

In particular, maintain an implicit, unsigned Z value initialized to 0. Then, introduce a LayerOp/ZOp/... that bumps Z with +1. When drawing, sort by Z first, then ops order as usual.

To draw a popup you do something like:

defer op.Push(ops).Pop()
... draw popup content ...

nested popups work as expected, and without inter-widget coordination:

defer op.Push(ops).Pop()
... draw popup content ...
defer op.Push(ops).Pop()
... draw secondary popup ...

With LayerOp/ZOp I don't see a need to know global coordinates for right-click popups and dropdowns; you draw the popup in local coordinates, and the LayerOp makes sure it appears on top of everything else.

Another thing that occurred to me is, are we spending too much effort making sure popups can resize and position themselves inside their owner window? In other toolkits, popups are not clipped to the window bounds and therefore it isn't necessary to be clever with position and size. Of course, implementing Gio support for drawing outside the window is not trivial, and there is many advantages to keeping all UI inside the window, in particular for fullscreen windows and on mobile.

Note that I don't have a good answer for the case of a modal centered in its window, expanded to take up all available space.


#166 WASM Keyboard issues 16 days ago

Comment by ~eliasnaur on ~eliasnaur/gio


#165 Gio cross-compilation for linux, build gioui.org/app/internal/glimpl: cannot load gioui.org/app/internal/glimpl: no Go source files 16 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.


#165 Gio cross-compilation for linux, build gioui.org/app/internal/glimpl: cannot load gioui.org/app/internal/glimpl: no Go source files 16 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


#164 Proper modal/z-index/overlay support (proposal) 16 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.


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


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.