9 ms·

Gio – write immediate-mode GUI programs in Go

181 points by rahimnathwani 5y ago

rob74 5y ago
I've been following the evolution of GUI bindings/native solutions in Go for a while now, and unfortunately all attempts at "Go-native" GUIs like this one have stalled long before they could achieve even a small fraction of the functionality of "established" frameworks like Qt or GTK (although I'm not sure that's even a goal for this project). That said, I wish them (and the other projects which are still active) good luck...
- daenney 5y ago
  It’s definitely a hard thing. Gio is still actively developed and it can already do useful things. On the not 100% native side there’s Fyne which seems to only depend on xorg development headers. It can do a lot.
- jonathanstrange 5y ago
  The Fyne developers are still very active. I don't think it's useful for more than small utilities in its current state, but I hope they'll implement some well-working multiline rich text editing soon. This is the area in which most homebrewn GUIs tend to fail. Rich text editing is surprisingly hard to get right and reasonably platform-compliant.
- psanford 5y ago
  Gio development isn't stalled.
  - sigzero 5y ago
    He didn't say it was. He was talking about "in general" and at the end even wishes them good luck.
jay_kyburz 5y ago
Do you think the UI is supposed to fly off and spin around in space when you click on it? https://imgur.com/a/sDmUA2x https://imgur.com/a/sDmUA2x
- jay_kyburz 5y ago
  Oh, it happens when you hit the transform checkbox.
pansa2 5y ago
It's good to see an example of Go running in the browser via WebAssembly. I've been trying to decide between Go and C++ for targeting WASM, but it's not clear whether Go is a good choice for this and whether WASM support is a priority for the language's developers.
- xyzzy_plugh 5y ago
  Go is not currently a good choice. The runtime is quite inefficient and performance is abysmal. Not to mention the huge binaries. It'll get there, with time, but for now I'd avoid it for anything serious. Tinygo is a bit better in this regard.
vincnetas 5y ago
Im gonna be grumpy old man. It's nice to play with new things, but it's really sad when UI conventions from OS is not implemented. This makes using this UI very frustrating: Triple click on the text. Expected whole paragraph to be selected. In input field click Cmd+A to select all text. Does not work as expected on mac. Copy paste does not work. Start selecting text but release mouse outside of the widget. Text selecting gets stuck. Text navigation in text field does not work Cmd - left/right. And these are from 5 minutes of playing with it. ps: im on mac+safari
- daenney 5y ago
  I think this is more of an artifact of the browser/WebGL things still being experimental. I don’t observe broken behaviours around copy paste or text selection if I run the example apps natively.
- buffrr 5y ago
  I have been following Gio development for quite some time, and it's still in the early stages. Text selection was added recently. It could be better but it's a good start. Double click to select a word and triple click to select paragraph doesn't work for me either but can't reproduce some of the other issues running it natively.
- nyanpasu64 5y ago
  I can't right-click a static/input text selection and get a menu (whether a browser menu or a non-native menu) with the ability to copy and paste and such.
- user-the-name 5y ago
  Also, no accessibility. macOS has amazing support for making its UI accessible to a wider variety of people, but immediate mode UIs throw this all out the window.
- rob74 5y ago
  Ok, let's try to say "the glass is already 20% full, not 80% empty" - there are still lots of things missing, but hey, it's still early days... My pet peeve with most "home-grown" GUI frameworks is relatively subtle and probably hard to implement, but it's an example why developing a GUI framework (especially a platform-independent one) from scratch is hard: no subpixel rendering for text (only "classic" antialiasing). This makes these UIs look strange on a "normal-DPI" monitor (which are getting rarer these days, but I still have some and I'm not gonna throw them away anytime soon).
ktpsns 5y ago
Immediate mode GUIs seem to be some "fresh wind" to desktop GUI toolkits. Apparently they are heavily motivated by gaming and 3D focussed applications. I wonder whether they are also play a role in traditional desktops. The Gio kitchen sink example counts hundred lines of code (https://git.sr.ht/~eliasnaur/gio-example/tree/main/kitchen/kitchen.go https://git.sr.ht/~eliasnaur/gio-example/tree/main/kitchen/k...), but for instance Dear ImGui examples (https://github.com/ocornut/imgui https://github.com/ocornut/imgui) are suprisingly short and require no headache with layouting containers. I could imagine that coding GUIs from the scratch is "fun again" with such a toolkit. Has anybody carried out a larger traditional (i.e. non 3D focussed) application with an immediate mode GUI toolkit?
- flohofwoe 5y ago
  Check out the Dear ImGui screenshot threads, there are quite a few examples of applications with complex UI in there: https://github.com/ocornut/imgui/issues/3488 https://github.com/ocornut/imgui/issues/3488
- whizzter 5y ago
  Not that I know of, the issue is often that most of them run through graphics API bindings currently. In many ways immediate mode UI's is a relative of declarative UI's like React and I think we might see hybrids or implementations of either on top of the other. Why? Right now immediate mode UI's often lack accessibility,etc and since it's often game/graphics focused there has been little push to fix this afaik. But there really is little reason not to implement an im-gui that renders to a diff-able tree that then is translated to "Native UI components". Imo one big reason why declarative UI's hasn't caught on is because C/C++ really don't have the best ergonomics for building "flexible" data structures or immutable updates, by turning it around to using im-gui style rendering it could probably be solved fairly smoothly.
  - flohofwoe 5y ago
    Here's an experiment which implements an immediate mode UI on top of HTML instead of a triangle rendering engine: https://games.greggman.com/game/imhui-first-thoughts/ https://games.greggman.com/game/imhui-first-thoughts/ The term "immediate mode" is only about the API, not about how things are implemented under the hood, e.g. an immediate mode UI can map to traditional stateful UIs, it's just not done yet very often because of ImGui's roots in the gamedev world (where it is important to easily integrate with existing game rendering engines).
gher-shyu3i 5y ago
golang lacks the language facilities to implement GUIs in a concise manner. This is one place where inheritance makes things a lot easier.
- _ph_ 5y ago
  I don't think you need inheritance for this at all. Inheritance might make providing an API a little bit easier, but it is not required, especially not for the consumer of an API. That Go structs have methods and you can embed structs into other structs and also be able to call those methods gives just enough "object orientation" which is necessary. The Go gtk bindings are a good example for this. For the user, they feel like a normal object oriented API.
  - gher-shyu3i 5y ago
    Strictly speaking, no language features are required other than the bare minimum, and we can write everything in assembly. The fact of the matter is that golang remains has failed to make headway into the UI space, and its language features make it very poor to work with for large code bases.
    - jonathanstrange 5y ago
      I agreed with you when you were talking about inheritance, but the claim that Go is not good for working with large code bases seems odd to me. Working with large codebases was one of Go's design goals. The idea is to split up programs into small packages with clear APIs, and these can be developed and maintained independently by hundreds of developers. I'd say it works quite well. (I'm not claiming it's the best, just that it works well. Technically, I'd still prefer Ada's extreme modularity with explicit interface definitions.)
      - gher-shyu3i 5y ago
        > Working with large codebases was one of Go's design goals. Which they failed to meet. There is nothing special in golang that is designed for large codebases. The opposite in fact, things like how they designed interfaces is counter to large code bases. There are much better languages that do well in large code bases.
ClawsOnPaws 5y ago
I know that this project is still in very early stages, however as I often do, I've come here to mention accessibility. I've run the examples on both Mac and Windows, and as expected, I can't use either of them. This is not a strict criticism yet and I'm aware how difficult it is to interface with accessibility API's, but I do hope that if this project does make it far enough that this will be considered. Pretty much everything that draws their UI directly to the screen using OpenGL or similar immediately makes me think that I probably don't even need to try the program to know that it's inaccessible, and more often than not I'm right. If you're building an app using these gui toolkits, please do keep this in mind.
- ClumsyPilot 5y ago
  This is the one real (and legal) reason why people should actually use OS UI. To replicate this functionality is a tall order. The 'looks native' thing is mostly noise
- pqb 5y ago
  This, hundreds times this. I can't say how many years in a row I was experimenting with various GUI toolkits, libraries and concepts of an application like rxi/lite editor [0]. While I saw many good looking implementations but the very first what caught my attention was lack of any kind support to screen-reading software or problem with displaying right-click context menus. I even remember previous HN discussion when I pointed out few projects that could provide some screen-readers support [1]. Sadly, I would say 95% of all GUIs I know do not care about the accessibility. From the positive side, I am glad more and more hackers on HN focus on that matter. Also worth noting big players on the market really do take that point seriously, e.g. Flutter has a Semantics tag [2]. [0]: https://github.com/rxi/lite https://github.com/rxi/lite [1]: https://news.ycombinator.com/item?id=26223380 https://news.ycombinator.com/item?id=26223380 [2]: https://api.flutter.dev/flutter/widgets/Semantics-class.html https://api.flutter.dev/flutter/widgets/Semantics-class.html
  - amelius 5y ago
    In my opinion, accessibility should be implemented at the OS level. The OS can, for example, run OCR on the entire screen and turn bitmaps into selectable text, read text out loud, etc. This kind of functionality shouldn't be replicated on a per-app basis. Accessibility of browsers is usually considered to be very good, but browsers are almost OSes, so why not lift this one more level into the OS?
Zababa 5y ago
Are there any more resources about immediate-mode GUI compared to retained-mode? I've read https://eliasnaur.com/blog/immediate-mode-gui-programming https://eliasnaur.com/blog/immediate-mode-gui-programming and I'm not sure I get it exactly. Is this because retained-mode toolkits don't offer enough control to developers so they want something lower level?
- rahimnathwani 5y ago
  Here are others recommended by Gio's author: https://caseymuratori.com/blog_0001 http://sol.gfxile.net/imgui/ http://www.johno.se/book/imgui.html https://github.com/ocornut/imgui
pwdisswordfish8 5y ago
Should I even bother mentioning GIO, an I/O library closely tied to Gtk, given that nobody cares about name clashes anymore? https://developer.gnome.org/gio/2.68/ https://developer.gnome.org/gio/2.68/
- Zababa 5y ago
  Is there a tool that allows for checking such name clashes, ideally by specifying the domain to see how close you are?
  - zserge 5y ago
    You mean like a web search engine? A quick search on "gio lib" shows a wiki for Gtk's GIO as the first result. You might narrow down the search adding domain-specific keywords to it, like "gio lib golang" to find something like this - https://github.com/vlorc/gioc https://github.com/vlorc/gioc (completely different field and name, but still can be found).
    - Zababa 5y ago
      In that particular case a web search works, sure. But for most name clashes that I see, it's often tools that are well known in some domains but not so much in others.
    - sp1rit 5y ago
      Having worked with GIO just yesterday I've got to say that the name GIO on it's own is not great in this modern age of the internet. Because searching "gio menuitem" returns a lot more pizza than development docs :). Prefixing my search request with glib (which gio is a part of) solved that for me.
- throwaway894345 5y ago
  It's always interesting to hear where people draw lines in their complaints about overloading things. I remember for about 4 years after Go came out, people complained that it overloaded the name of the board game. No one cared that they both overloaded the verb though. Similarly, no one was upset that Python overloaded a kind of snake (yes, I know Python comes from "Monte Python") or that Rust overloads iron-oxide or Ruby overloads the gemstone or etc.
anthk 5y ago
&errors.errorString{s:"no support for OpenGL ES 3 nor EXT_sRGB"} Old computers with GL 2.1 adapters are fucked.

181 points by rahimnathwani 5y ago

I've been following the evolution of GUI bindings/native solutions in Go for a while now, and unfortunately all attempts at "Go-native" GUIs like this one have stalled long before they could achieve even a small fraction of the functionality of "established" frameworks like Qt or GTK (although I'm not sure that's even a goal for this project). That said, I wish them (and the other projects which are still active) good luck...

daenney 5y ago
It’s definitely a hard thing. Gio is still actively developed and it can already do useful things. On the not 100% native side there’s Fyne which seems to only depend on xorg development headers. It can do a lot.
jonathanstrange 5y ago
The Fyne developers are still very active. I don't think it's useful for more than small utilities in its current state, but I hope they'll implement some well-working multiline rich text editing soon. This is the area in which most homebrewn GUIs tend to fail. Rich text editing is surprisingly hard to get right and reasonably platform-compliant.
psanford 5y ago
Gio development isn't stalled.
- sigzero 5y ago
  He didn't say it was. He was talking about "in general" and at the end even wishes them good luck.

jay_kyburz 5y ago

Do you think the UI is supposed to fly off and spin around in space when you click on it? https://imgur.com/a/sDmUA2x https://imgur.com/a/sDmUA2x

jay_kyburz 5y ago
Oh, it happens when you hit the transform checkbox.

pansa2 5y ago

It's good to see an example of Go running in the browser via WebAssembly. I've been trying to decide between Go and C++ for targeting WASM, but it's not clear whether Go is a good choice for this and whether WASM support is a priority for the language's developers.

xyzzy_plugh 5y ago
Go is not currently a good choice. The runtime is quite inefficient and performance is abysmal. Not to mention the huge binaries. It'll get there, with time, but for now I'd avoid it for anything serious. Tinygo is a bit better in this regard.

vincnetas 5y ago

Im gonna be grumpy old man. It's nice to play with new things, but it's really sad when UI conventions from OS is not implemented. This makes using this UI very frustrating: Triple click on the text. Expected whole paragraph to be selected. In input field click Cmd+A to select all text. Does not work as expected on mac. Copy paste does not work. Start selecting text but release mouse outside of the widget. Text selecting gets stuck. Text navigation in text field does not work Cmd - left/right. And these are from 5 minutes of playing with it. ps: im on mac+safari

daenney 5y ago
I think this is more of an artifact of the browser/WebGL things still being experimental. I don’t observe broken behaviours around copy paste or text selection if I run the example apps natively.
buffrr 5y ago
I have been following Gio development for quite some time, and it's still in the early stages. Text selection was added recently. It could be better but it's a good start. Double click to select a word and triple click to select paragraph doesn't work for me either but can't reproduce some of the other issues running it natively.
nyanpasu64 5y ago
I can't right-click a static/input text selection and get a menu (whether a browser menu or a non-native menu) with the ability to copy and paste and such.
user-the-name 5y ago
Also, no accessibility. macOS has amazing support for making its UI accessible to a wider variety of people, but immediate mode UIs throw this all out the window.
rob74 5y ago
Ok, let's try to say "the glass is already 20% full, not 80% empty" - there are still lots of things missing, but hey, it's still early days... My pet peeve with most "home-grown" GUI frameworks is relatively subtle and probably hard to implement, but it's an example why developing a GUI framework (especially a platform-independent one) from scratch is hard: no subpixel rendering for text (only "classic" antialiasing). This makes these UIs look strange on a "normal-DPI" monitor (which are getting rarer these days, but I still have some and I'm not gonna throw them away anytime soon).

ktpsns 5y ago

Immediate mode GUIs seem to be some "fresh wind" to desktop GUI toolkits. Apparently they are heavily motivated by gaming and 3D focussed applications. I wonder whether they are also play a role in traditional desktops. The Gio kitchen sink example counts hundred lines of code (https://git.sr.ht/~eliasnaur/gio-example/tree/main/kitchen/kitchen.go https://git.sr.ht/~eliasnaur/gio-example/tree/main/kitchen/k...), but for instance Dear ImGui examples (https://github.com/ocornut/imgui https://github.com/ocornut/imgui) are suprisingly short and require no headache with layouting containers. I could imagine that coding GUIs from the scratch is "fun again" with such a toolkit. Has anybody carried out a larger traditional (i.e. non 3D focussed) application with an immediate mode GUI toolkit?

flohofwoe 5y ago
Check out the Dear ImGui screenshot threads, there are quite a few examples of applications with complex UI in there: https://github.com/ocornut/imgui/issues/3488 https://github.com/ocornut/imgui/issues/3488
whizzter 5y ago
Not that I know of, the issue is often that most of them run through graphics API bindings currently. In many ways immediate mode UI's is a relative of declarative UI's like React and I think we might see hybrids or implementations of either on top of the other. Why? Right now immediate mode UI's often lack accessibility,etc and since it's often game/graphics focused there has been little push to fix this afaik. But there really is little reason not to implement an im-gui that renders to a diff-able tree that then is translated to "Native UI components". Imo one big reason why declarative UI's hasn't caught on is because C/C++ really don't have the best ergonomics for building "flexible" data structures or immutable updates, by turning it around to using im-gui style rendering it could probably be solved fairly smoothly.
- flohofwoe 5y ago
  Here's an experiment which implements an immediate mode UI on top of HTML instead of a triangle rendering engine: https://games.greggman.com/game/imhui-first-thoughts/ https://games.greggman.com/game/imhui-first-thoughts/ The term "immediate mode" is only about the API, not about how things are implemented under the hood, e.g. an immediate mode UI can map to traditional stateful UIs, it's just not done yet very often because of ImGui's roots in the gamedev world (where it is important to easily integrate with existing game rendering engines).

gher-shyu3i 5y ago

golang lacks the language facilities to implement GUIs in a concise manner. This is one place where inheritance makes things a lot easier.

_ph_ 5y ago
I don't think you need inheritance for this at all. Inheritance might make providing an API a little bit easier, but it is not required, especially not for the consumer of an API. That Go structs have methods and you can embed structs into other structs and also be able to call those methods gives just enough "object orientation" which is necessary. The Go gtk bindings are a good example for this. For the user, they feel like a normal object oriented API.
- gher-shyu3i 5y ago
  Strictly speaking, no language features are required other than the bare minimum, and we can write everything in assembly. The fact of the matter is that golang remains has failed to make headway into the UI space, and its language features make it very poor to work with for large code bases.
  - jonathanstrange 5y ago
    I agreed with you when you were talking about inheritance, but the claim that Go is not good for working with large code bases seems odd to me. Working with large codebases was one of Go's design goals. The idea is to split up programs into small packages with clear APIs, and these can be developed and maintained independently by hundreds of developers. I'd say it works quite well. (I'm not claiming it's the best, just that it works well. Technically, I'd still prefer Ada's extreme modularity with explicit interface definitions.)
    - gher-shyu3i 5y ago
      > Working with large codebases was one of Go's design goals. Which they failed to meet. There is nothing special in golang that is designed for large codebases. The opposite in fact, things like how they designed interfaces is counter to large code bases. There are much better languages that do well in large code bases.

ClawsOnPaws 5y ago

I know that this project is still in very early stages, however as I often do, I've come here to mention accessibility. I've run the examples on both Mac and Windows, and as expected, I can't use either of them. This is not a strict criticism yet and I'm aware how difficult it is to interface with accessibility API's, but I do hope that if this project does make it far enough that this will be considered. Pretty much everything that draws their UI directly to the screen using OpenGL or similar immediately makes me think that I probably don't even need to try the program to know that it's inaccessible, and more often than not I'm right. If you're building an app using these gui toolkits, please do keep this in mind.

ClumsyPilot 5y ago
This is the one real (and legal) reason why people should actually use OS UI. To replicate this functionality is a tall order. The 'looks native' thing is mostly noise
pqb 5y ago
This, hundreds times this. I can't say how many years in a row I was experimenting with various GUI toolkits, libraries and concepts of an application like rxi/lite editor [0]. While I saw many good looking implementations but the very first what caught my attention was lack of any kind support to screen-reading software or problem with displaying right-click context menus. I even remember previous HN discussion when I pointed out few projects that could provide some screen-readers support [1]. Sadly, I would say 95% of all GUIs I know do not care about the accessibility. From the positive side, I am glad more and more hackers on HN focus on that matter. Also worth noting big players on the market really do take that point seriously, e.g. Flutter has a Semantics tag [2]. [0]: https://github.com/rxi/lite https://github.com/rxi/lite [1]: https://news.ycombinator.com/item?id=26223380 https://news.ycombinator.com/item?id=26223380 [2]: https://api.flutter.dev/flutter/widgets/Semantics-class.html https://api.flutter.dev/flutter/widgets/Semantics-class.html
- amelius 5y ago
  In my opinion, accessibility should be implemented at the OS level. The OS can, for example, run OCR on the entire screen and turn bitmaps into selectable text, read text out loud, etc. This kind of functionality shouldn't be replicated on a per-app basis. Accessibility of browsers is usually considered to be very good, but browsers are almost OSes, so why not lift this one more level into the OS?

Zababa 5y ago

Are there any more resources about immediate-mode GUI compared to retained-mode? I've read https://eliasnaur.com/blog/immediate-mode-gui-programming https://eliasnaur.com/blog/immediate-mode-gui-programming and I'm not sure I get it exactly. Is this because retained-mode toolkits don't offer enough control to developers so they want something lower level?

rahimnathwani 5y ago
Here are others recommended by Gio's author: https://caseymuratori.com/blog_0001 http://sol.gfxile.net/imgui/ http://www.johno.se/book/imgui.html https://github.com/ocornut/imgui

pwdisswordfish8 5y ago

Should I even bother mentioning GIO, an I/O library closely tied to Gtk, given that nobody cares about name clashes anymore? https://developer.gnome.org/gio/2.68/ https://developer.gnome.org/gio/2.68/

Zababa 5y ago
Is there a tool that allows for checking such name clashes, ideally by specifying the domain to see how close you are?
- zserge 5y ago
  You mean like a web search engine? A quick search on "gio lib" shows a wiki for Gtk's GIO as the first result. You might narrow down the search adding domain-specific keywords to it, like "gio lib golang" to find something like this - https://github.com/vlorc/gioc https://github.com/vlorc/gioc (completely different field and name, but still can be found).
  - Zababa 5y ago
    In that particular case a web search works, sure. But for most name clashes that I see, it's often tools that are well known in some domains but not so much in others.
  - sp1rit 5y ago
    Having worked with GIO just yesterday I've got to say that the name GIO on it's own is not great in this modern age of the internet. Because searching "gio menuitem" returns a lot more pizza than development docs :). Prefixing my search request with glib (which gio is a part of) solved that for me.
throwaway894345 5y ago
It's always interesting to hear where people draw lines in their complaints about overloading things. I remember for about 4 years after Go came out, people complained that it overloaded the name of the board game. No one cared that they both overloaded the verb though. Similarly, no one was upset that Python overloaded a kind of snake (yes, I know Python comes from "Monte Python") or that Rust overloads iron-oxide or Ruby overloads the gemstone or etc.

anthk 5y ago

&errors.errorString{s:"no support for OpenGL ES 3 nor EXT_sRGB"} Old computers with GL 2.1 adapters are fucked.