~beikege: another good catch, thank you.

~egonelbre: thanks, fixed.

go get gioui.org@7593558fe36b895b should fix both issues.

Currently I'm unable to figure out how to set cursor for different regions without causing redraws. https://github.com/egonelbre/expgio/blob/event-filters/cursors/main.go#L100.

Here is some of the refactoring you'll need:

gofmt -w -r "system.DestroyEvent -> app.DestroyEvent" .
gofmt -w -r "system.FrameEvent -> app.FrameEvent" .
gofmt -w -r "layout.NewContext -> app.NewContext" .
gofmt -w -r "op.InvalidateOp{}.Add(gtx.Ops) -> gtx.Execute(op.InvalidateCmd{})" .
goimports -w .

Remove any code related to package "gioui.org/profile"

For gesture.drag:

for _, e := range drag.Update(gtx.Metric, gtx, gesture.Both) {

// ==>

for {
	e, ok := drag.Update(gtx.Metric, gtx.Source, gesture.Both)
	if !ok {
		break
	}

Didn't get further at the moment.

I remembered trying to fix something related to custom decorations for Windows, but I didn't get it fixed, due to time constraints.

WIP https://git.sr.ht/~egonelbre/gio/commit/55782d765b39b12fe747ccf207290b4789f0c852

I think it was something that the widget/material/decorations.go caused buttons to be not correctly handled... unfortunately don't recall the details anymore. It could've been something with regards to click boundaries being wrong or something.

Also, I'm unsure whether this information is helpful :D...

It also seems related to iframes, because https://gioui.org/files/wasm/kitchen/index.html does work perfectly.

So, while debugging things it seems that Chrome (Version 117.0.5938.150 64-bit) ends up drawing the kitchen example background black on gioui.org .

https://imgur.com/aj8T0V9

This seems to be related to using desynchronized: true in https://git.sr.ht/~eliasnaur/gio/tree/main/item/app/gl_js.go#L23

I'm unsure whether this is a limitation of Chrome, i.e. it doesn't support alpha in desynchronized WebGL contexts. Or it's a Chrome bug only related to Windows, because the problem doesn't happen on Mac. Or whether it's related to my graphics card.

Either way setting desynchronized: false made the problem go away.

Sometimes it manages to start blending, but somewhat glitchy, and I'm unsure in what scenarios.

For platforms that support it, we should use the system colors.

Whoops, I didn't think my e-mail would go to a list to be honest, neither did I think it would open an issue, so please feel free to close it.

But while we are here:

Sure, in general what you say could hold. But in my specific case, it's only a desktop/android app (no web), with only simple UI elements (none of the example you mention should be present). Which is why I was disappointed that imho there was no real technical argument behind the decision. At the end of the day it was more like a political/popularity based decision.

But yes, I suppose a super shiny example somewhere of something build with Gio might go a long way of changing these kind of popularity based choices.

On Fri, 19 May 2023 at 17:46, ~egonelbre outgoing@sr.ht wrote:

While I'm a big fan of Gio and Go and the approach in general, I do agree that there's a danger of not having easily usable widgets that have already been built for common frameworks.

Let's take something like animation support https://rive.app/. This is a common way to make apps feel more engaging to use, it's quite a bit of work to implement the logic for them.

Or, you could then look into scanning QR codes with the camera and live interacting with the input.

Or maybe embedding videos to the application.

Or embedding a browser and interacting with it.

---

Overall, it did seem like a fair evaluation of Gio. Without having a good high-quality example UI/UX it is very difficult for people to see what's possible.

And, yes, I'm rooting for Gio as well.

All the best,

• Egon

On Fri, May 19, 2023 at 6:30 PM ~Mathieu Lonjaret outgoing@sr.ht wrote:

Hello,

First of all, many thanks for Gio.

As a long time Go user I was happy to (re)discover its existence when I was tasked to build a desktop/android app. Especially after I saw that Tailscale (big fan here) was using it too now. I started prototyping, going through all the pain points I was expecting could be problematic when working with Go/Gio , and I was happy to find out I could make it all work so far (talking to an android through USB with MTP was such an example). Unfortunately, afterwards, we get this (redacted, and paraphrased, for confidentiality) e-mail from the client, after we sent our first "report":

---

I've gone through the pros and cons of Gio, both internally and with the mobile/UI/UX team we are collaborating with. Honestly, I don't think Gio is the right way to go. We would feel much more comfortable going with a framework that is commonplace and backed by a large community of developers, contributors, users and corporations. Gio feels very obscure, and within the teams I've consulted, very few have even heard of it.

For XXX to move forward with Gio, the framework would need to provide XXX with features that other more mainstream frameworks cannot provide. At present, it seems we have the opposite—the mainstream frameworks like React Native, Tamarin, Flutter, etc. offer far more flexibility and features. By their very nature, mainstream frameworks are commonly used, which means should we ever need to develop field-to-cloud beyond the initial project, we won't have an issue finding quality candidates. In addition, the modules/plugins available within mainstream frameworks are extensive. Gio appears to have very few, which will require reinventing-the-wheel every time we need a new widget. I'm a little unsure as to the current widgets available in Gio, largely because the framework is not used that much, and very little quality documentation exists.

I understand Gio has been used for a handful of apps, namely Tailscale, but even these examples aren't great. All the apps I've reviewed, that have been built with Gio, are very basic and outdated in their UI/UX. We are going to need a lot of flexibility with ZZZ, and deliver an app that is very user friendly, performant, and slick.

Whilst Gio seems good for very lightweight scenarios, ZZZ is going to demand more. Please could you re-evaluate and select a mainstream framework to develop ZZZ? One that allows us to leverage a large suite of existing plugins, has extensive documentation, a large and active user community, and backed by big use cases.

---

I honestly think most of it is non-valid. Like, I would expect to be able to find everything I need in Gio in terms of UI , and they obviously haven't grasped how attractive the immediate mode is. And they don't get that an app written with Gio could be maintained by any decent Go programmer (which there are "plenty" of). But at the end of the day, we have to please the client, so we're gonna go with something like React. And that makes me sad.

Anyway, sorry about the rant. Just wanted you to know that some of us are rooting for Gio, but that the world is not yet ready for it. :(

Regards, Mathieu

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/502

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/502#event-238809

While I'm a big fan of Gio and Go and the approach in general, I do agree that there's a danger of not having easily usable widgets that have already been built for common frameworks.

Let's take something like animation support https://rive.app/. This is a common way to make apps feel more engaging to use, it's quite a bit of work to implement the logic for them.

Or, you could then look into scanning QR codes with the camera and live interacting with the input.

Or maybe embedding videos to the application.

Or embedding a browser and interacting with it.

---

Overall, it did seem like a fair evaluation of Gio. Without having a good high-quality example UI/UX it is very difficult for people to see what's possible.

And, yes, I'm rooting for Gio as well.

All the best,

• Egon

On Fri, May 19, 2023 at 6:30 PM ~Mathieu Lonjaret outgoing@sr.ht wrote:

Hello,

First of all, many thanks for Gio.

As a long time Go user I was happy to (re)discover its existence when I was tasked to build a desktop/android app. Especially after I saw that Tailscale (big fan here) was using it too now. I started prototyping, going through all the pain points I was expecting could be problematic when working with Go/Gio , and I was happy to find out I could make it all work so far (talking to an android through USB with MTP was such an example). Unfortunately, afterwards, we get this (redacted, and paraphrased, for confidentiality) e-mail from the client, after we sent our first "report":

---

I've gone through the pros and cons of Gio, both internally and with the mobile/UI/UX team we are collaborating with. Honestly, I don't think Gio is the right way to go. We would feel much more comfortable going with a framework that is commonplace and backed by a large community of developers, contributors, users and corporations. Gio feels very obscure, and within the teams I've consulted, very few have even heard of it.

For XXX to move forward with Gio, the framework would need to provide XXX with features that other more mainstream frameworks cannot provide. At present, it seems we have the opposite—the mainstream frameworks like React Native, Tamarin, Flutter, etc. offer far more flexibility and features. By their very nature, mainstream frameworks are commonly used, which means should we ever need to develop field-to-cloud beyond the initial project, we won't have an issue finding quality candidates. In addition, the modules/plugins available within mainstream frameworks are extensive. Gio appears to have very few, which will require reinventing-the-wheel every time we need a new widget. I'm a little unsure as to the current widgets available in Gio, largely because the framework is not used that much, and very little quality documentation exists.

I understand Gio has been used for a handful of apps, namely Tailscale, but even these examples aren't great. All the apps I've reviewed, that have been built with Gio, are very basic and outdated in their UI/UX. We are going to need a lot of flexibility with ZZZ, and deliver an app that is very user friendly, performant, and slick.

Whilst Gio seems good for very lightweight scenarios, ZZZ is going to demand more. Please could you re-evaluate and select a mainstream framework to develop ZZZ? One that allows us to leverage a large suite of existing plugins, has extensive documentation, a large and active user community, and backed by big use cases.

---

I honestly think most of it is non-valid. Like, I would expect to be able to find everything I need in Gio in terms of UI , and they obviously haven't grasped how attractive the immediate mode is. And they don't get that an app written with Gio could be maintained by any decent Go programmer (which there are "plenty" of). But at the end of the day, we have to please the client, so we're gonna go with something like React. And that makes me sad.

Anyway, sorry about the rant. Just wanted you to know that some of us are rooting for Gio, but that the world is not yet ready for it. :(

Regards, Mathieu

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/502

Ok, yeah. It seems that handling the "no baseline" case is the main option at the moment.

I wonder whether we could treat Baseline: 0 as no-baseline. We could also use something like Baseline: math.MaxInt, but that feels rather hacky. Adding a field, of course, would be the clearest.

I also feel like we are missing the difference between intrinsically and extrinsically sized widgets. We treat everything as extrinsically sized. But, I don't have a better solution for that.

I guess we can do the straightforward thing first and later try to figure out something better.