Gio – write immediate-mode GUI programs in Go(gioui.org)
gioui.org
Gio – write immediate-mode GUI programs in Go
https://gioui.org/
95 comments
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.
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
[1]: https://news.ycombinator.com/item?id=26223380
[2]: https://api.flutter.dev/flutter/widgets/Semantics-class.html
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
[1]: https://news.ycombinator.com/item?id=26223380
[2]: https://api.flutter.dev/flutter/widgets/Semantics-class.html
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?
> In my opinion, accessibility should be implemented at the OS level.
Which it is. Apple has been praised for the accessibility of both macOS and iOS for years if not decades, accessibility concerns have been baked into Cocoa forever. And accessibility is literally a top level category of the Settings app.
And I know that Windows has been improving by leaps and bounds.
> The OS can, for example, run OCR on the entire screen and turn bitmaps into selectable text, read text out loud, etc
That exists (look up VoiceOver Recognition). However it can not be reliable, and will never be anywhere near as good as actual semantic annotation.
Image recognition has no way to understand that the physical UI layout has no relation to its logical setup, nor does it have any way to differentiate between semantic and decorative content, or to see through invisibility to know that a button is a menu versus an action.
Which it is. Apple has been praised for the accessibility of both macOS and iOS for years if not decades, accessibility concerns have been baked into Cocoa forever. And accessibility is literally a top level category of the Settings app.
And I know that Windows has been improving by leaps and bounds.
> The OS can, for example, run OCR on the entire screen and turn bitmaps into selectable text, read text out loud, etc
That exists (look up VoiceOver Recognition). However it can not be reliable, and will never be anywhere near as good as actual semantic annotation.
Image recognition has no way to understand that the physical UI layout has no relation to its logical setup, nor does it have any way to differentiate between semantic and decorative content, or to see through invisibility to know that a button is a menu versus an action.
That is not really going to work, at all. To have a good experience, a screen reader needs more contextual information than just the text.
OSes do provide accessibility APIs - and usually if you use one of the more supported graphic toolkits there are somewhat easy ways to integrate directly in semantic ways, without needing to OCR and do fortune telling.
Usually it means that you need a deferred mode semantic tree of the application for accessibility UI to walk through, though.
Usually it means that you need a deferred mode semantic tree of the application for accessibility UI to walk through, though.
If we want more accessible UIs, we need to demand better standard accessibility APIs from OS vendors Microsoft and Apple.
Unity has no official support for screenreaders or colorblind modes. Unreal has both. If an major game engine developer like Unity cannot be bothered to add support, can we really expect the little developer hacking away on some OpenGL side project to?
Most people working with OpenGL use GLFW (or sometimes SDL), neither have any cross-platform API for supporting screen readers. Why? Because not only do Windows and MacOS have different APIs, but different screen readers, braille displays, etc. have different APIs.
But okay - let's look at the web. It's the most accessible platform of them all, right? What have Google/Apple/Mozilla done to support developers adding screenreader support from WebGL and Canvas-based applications? -> not a whole lot. You need to inject text into a hidden div, which also has performance implications so you need to build a UI to toggle it on/off or detect accessibility the way Flutter Web does.
We should have better accessibility, but as long as we expect developers to run through several hours/days of hoops to get even something basic working - it's just not going to happen, and that is mostly the fault of extremely poor platform APIs.
Unity has no official support for screenreaders or colorblind modes. Unreal has both. If an major game engine developer like Unity cannot be bothered to add support, can we really expect the little developer hacking away on some OpenGL side project to?
Most people working with OpenGL use GLFW (or sometimes SDL), neither have any cross-platform API for supporting screen readers. Why? Because not only do Windows and MacOS have different APIs, but different screen readers, braille displays, etc. have different APIs.
But okay - let's look at the web. It's the most accessible platform of them all, right? What have Google/Apple/Mozilla done to support developers adding screenreader support from WebGL and Canvas-based applications? -> not a whole lot. You need to inject text into a hidden div, which also has performance implications so you need to build a UI to toggle it on/off or detect accessibility the way Flutter Web does.
We should have better accessibility, but as long as we expect developers to run through several hours/days of hoops to get even something basic working - it's just not going to happen, and that is mostly the fault of extremely poor platform APIs.
> Unity has no official support for screenreaders or colorblind modes. Unreal has both. If an major game engine developer like Unity cannot be bothered to add support, can we really expect the little developer hacking away on some OpenGL side project to?
Games are special because the means of interaction is often a core part of the experience. An accessibility mode for a game can be a huge amount of work. Not to say that some people don't do that huge amount of work (which is great) but games lacking accessibility is no excuse to use game-like development practices to write apps that could otherwise be relatively easily made accessibile.
Games are special because the means of interaction is often a core part of the experience. An accessibility mode for a game can be a huge amount of work. Not to say that some people don't do that huge amount of work (which is great) but games lacking accessibility is no excuse to use game-like development practices to write apps that could otherwise be relatively easily made accessibile.
> extremely poor platform APIs
As a former member of the Windows accessibility team at Microsoft, I'd appreciate your thoughts on what makes the platform accessibility APIs extremely poor. I have my own thoughts on what makes them difficult to implement, but I'd like to hear your perspective first.
As a former member of the Windows accessibility team at Microsoft, I'd appreciate your thoughts on what makes the platform accessibility APIs extremely poor. I have my own thoughts on what makes them difficult to implement, but I'd like to hear your perspective first.
I've dabbled in this space and it would easily, easily be more code than all of Gio just to get basic accessibility integration in Windows. COM, OLE, a heavy bias towards automatically working with native UI elements which are obviously not used here. It's just not a user friendly API. Hell, that applies to anything that uses COM
Qt supports accessibility on windows without issues afaik, it's a couple thousand lines of code
Qt is retained, not immediate mode.
Could that be solved by having better golang bindings for COM/OLE? Is it a problem of too much boilerplate?
That's a big part of it. Another part is that most Go developers want to keep their Cgo dependencies as small as possible (preferably zero) for portability and performance reasons. It's also problematic that Go is not really OOP, and in particular immediate mode programming implies that state is inferred by the pass each frame -- meshing this with the COM/OLE model is bananas. You basically need to do everything the library is doing to draw, cache and render the UI again to render the state in COM. It's a ton of bookkeeping.
Worse still, while the Gio layout engine is pretty good at culling non-visible stuff, ultimately the framework doesn't know what will be visible until we're in GPU land, so there would have to be a ton of bookkeeping added to test if, for example, some text was clipped or if things were overlapping.
In practice, the best way to model things would be to just allow the developer to do something equivalent to pushing fields full of ARIA information like in the browser. But now you're losing all the advantages of the immediate mode and layout engine, etc.
It's a lose/lose situation, unfortunately.
I think the real solution is somewhere in the middle. I think screen readers need to grow some OCR abilities, and libraries like Gio need to learn some better navigation tech, like supporting tab, keyboard nav, etc. Something like that.
Worse still, while the Gio layout engine is pretty good at culling non-visible stuff, ultimately the framework doesn't know what will be visible until we're in GPU land, so there would have to be a ton of bookkeeping added to test if, for example, some text was clipped or if things were overlapping.
In practice, the best way to model things would be to just allow the developer to do something equivalent to pushing fields full of ARIA information like in the browser. But now you're losing all the advantages of the immediate mode and layout engine, etc.
It's a lose/lose situation, unfortunately.
I think the real solution is somewhere in the middle. I think screen readers need to grow some OCR abilities, and libraries like Gio need to learn some better navigation tech, like supporting tab, keyboard nav, etc. Something like that.
Screen readers doing OCR is a big no-no. There is no possible way that will have the effect you want it to have. The text-to-speech part is the absolute bare minimum of what a screen reader is actually doing. For example that would break horribly with the situation you describe, where some piece of text gets clipped.
Just IMO, it's unrealistic to expect to have an accessible GUI that stores no state, does none of that type of bookkeeping, has no OOP model, and only outputs to pixels. The point with these type of assistive technologies is that the user can't work with that type of visual data, they need more state presented to them. Sure, it makes everything easier to develop when you cut it all out and only use immediate mode, but that's exactly the problem: everything else has been cut out, on purpose.
Just IMO, it's unrealistic to expect to have an accessible GUI that stores no state, does none of that type of bookkeeping, has no OOP model, and only outputs to pixels. The point with these type of assistive technologies is that the user can't work with that type of visual data, they need more state presented to them. Sure, it makes everything easier to develop when you cut it all out and only use immediate mode, but that's exactly the problem: everything else has been cut out, on purpose.
Have you heard of the Screen Recognition feature in iOS 14? I haven't had a chance to use it myself yet. From what I've heard, it's impressive, but not a complete solution, at least not yet. Apple published a paper about it here:
https://machinelearning.apple.com/research/creating-accessib...
https://machinelearning.apple.com/research/creating-accessib...
That's quite interesting, thank you. I haven't heard of that. My only concern with that is, I hope some app developers don't see it as an excuse to avoid using the native accessibility APIs and adding the necessary properties to their controls.
> For example that would break horribly with the situation you describe, where some piece of text gets clipped.
Forgive my ignorance, but what should happen here? Let say I have a scrollable text pane with an entire novel in it.
I agree there should still be a mechanism to pass more accessibility data than OCR could extract. What is the bare minimum information that is required? Pretend there is no UX model -- arbitrary things could be presented (like in a video game).
In particular, with Gio there isn't necessarily a single set of widgets or UX. Gio has a small set of Material Design compliant widgets, but is mostly a library for composing immediate mode graphics. For example I have several custom widgets, some that only interact with the keyboard, some that don't have any text at all (just graphics or animations), one is a akin to a 2D-scrollable map, click-to-drag Google maps style. I'm not really sure where I'd begin in making these accessible. How should something like Google Earth be made accessible, ideally?
Forgive my ignorance, but what should happen here? Let say I have a scrollable text pane with an entire novel in it.
I agree there should still be a mechanism to pass more accessibility data than OCR could extract. What is the bare minimum information that is required? Pretend there is no UX model -- arbitrary things could be presented (like in a video game).
In particular, with Gio there isn't necessarily a single set of widgets or UX. Gio has a small set of Material Design compliant widgets, but is mostly a library for composing immediate mode graphics. For example I have several custom widgets, some that only interact with the keyboard, some that don't have any text at all (just graphics or animations), one is a akin to a 2D-scrollable map, click-to-drag Google maps style. I'm not really sure where I'd begin in making these accessible. How should something like Google Earth be made accessible, ideally?
really the major pain point is more the lack of cross platform APIs.
Such cross platform API would belong in a cross platform toolkit, it really makes no sense for Windows to provide that. For example Qt has a cross platform accessibility API, and GTK is currently working on making theirs cross platform. Maybe somebody should move this functionality out into a standalone library?
> Maybe somebody should move this functionality out into a standalone library?
I've been thinking about this for a while. Below is an edited excerpt from a message that I wrote to a colleague a few months ago, about how I think I should go about such a project:
---
I've been thinking about the problem of multiple programming languages, and even multiple programming styles within the same language. Do we implement a C library that would make hard-core Unix and Linux folks happy? A library in a subset of C++ that some developers of games and graphics would be comfortable with? A more modern style of C++ that would make some other developers happy? And where would that leave folks working in Java, or C# like the Unity crowd? Of course, different platforms have varying levels of support for different languages. And there are more languages coming into popularity or on the horizon, like Swift and Rust.
So I think what we really want is a cross-platform message format or protocol, with multiple implementations: multiple providers on the application/toolkit side, and multiple client libraries on the platform side. The client libraries could be written in each platform's native language (e.g. C++ for Windows, Java for Android, Swift for Apple platforms, or JavaScript for the web), and separately, provider libraries could be implemented in multiple languages. All major programming languages can work with binary data buffers. And since none of us want to work directly with those raw bytes, we could use an existing standard like Google Protocol Buffers, which already has implementations in several languages. Initially, for desktop and mobile platforms as well as web applications, this protocol would just be used internally between components in the same application process. But I can dream about platforms themselves adopting the protocol someday. There would have to be glue layers between cross-platform providers and platform-specific clients, but if we design this right, the glue could be kept pretty thin, with most of the complexity being kept on one side or the other, so we don't have a multiplication of effort for n toolkits or applications on m platforms.
I think the protocol should be push-based, rather than pull-based like Windows UI Automation and some other accessibility APIs. That is, the application/toolkit would push full information about objects in the accessibility tree when it first creates that tree, and incremental updates when objects are created or destroyed, when properties change, when text content changes, etc. That's probably the only thing that's going to work for the web platform, and I think it's a model that other platforms would do well to adopt. (It's probably too late for Windows, but I dream of replacing the current accessibility model on desktop Linux someday, after my non-compete with Microsoft expires.) The challenge with a push model is making it efficient; we don't want to re-push the whole contents of a large text box when the user types a single character, and when we do need to push all contents, we need to do so efficiently. And sometimes we really do need to push a lot of information. For example, for a text box, we need the screen coordinates of every character, plus all of the boundaries between words.
Luckily, a push-based accessibility architecture has been done before, internally in the Chromium browser engine. As you probably know, Chromium has a multi-process model, where web pages are rendered in sandboxed processes, which communicate with a master browser process that interfaces with the OS. The browser process is not allowed to do blocking IPC requests into the renderer processes, so it can't implement synchronous, pull-based accessibility APIs like UIA in the obvious way. So the Chromium team implemented a protocol where the renderer processes push their accessibility trees, and incremental updates to those trees, over to the browser process, which can then store the trees in memory and then provide information to UIA or other APIs on request. The pushed trees are comprehensive, including the information I mentioned about text. Chromium does this using its own binary protocol called Mojo, which is kind of like Protocol Buffers but strongly tied to Chromium. So, while I'll take design inspiration from Chromium, I probably won't take the actual protocol or code.
I also want my protocol to scale down to embedded platforms. Accessibility on devices running embedded software (i.e. not Windows or another general-purpose OS) is basically an unsolved problem; as far as I know, device makers have to implement their own custom self-voicing interfaces, if they do anything about the problem at all. But imagine a standard where a user can pull out their smartphone, connect to the specialized device over Bluetooth or WiFi, and get an accessible interface to the device on their phone. Yeah, I'm swinging for the fence with this project. To pull this off, I think the protocol would need to be not only push-based but streaming, allowing providers to send out accessibility information without having to build up and maintain much extra state in memory. This would also help with the immediate-mode GUIs that are used in some games and game development tools. If we design the protocol right, these immediate-mode toolkits should be able to push out accessibility information and events at the same time that they're making OpenGL (or similar) calls to draw the current frame, again without having to hold much extra state in memory, which is something that these toolkits try to avoid.
I've been thinking about this for a while. Below is an edited excerpt from a message that I wrote to a colleague a few months ago, about how I think I should go about such a project:
---
I've been thinking about the problem of multiple programming languages, and even multiple programming styles within the same language. Do we implement a C library that would make hard-core Unix and Linux folks happy? A library in a subset of C++ that some developers of games and graphics would be comfortable with? A more modern style of C++ that would make some other developers happy? And where would that leave folks working in Java, or C# like the Unity crowd? Of course, different platforms have varying levels of support for different languages. And there are more languages coming into popularity or on the horizon, like Swift and Rust.
So I think what we really want is a cross-platform message format or protocol, with multiple implementations: multiple providers on the application/toolkit side, and multiple client libraries on the platform side. The client libraries could be written in each platform's native language (e.g. C++ for Windows, Java for Android, Swift for Apple platforms, or JavaScript for the web), and separately, provider libraries could be implemented in multiple languages. All major programming languages can work with binary data buffers. And since none of us want to work directly with those raw bytes, we could use an existing standard like Google Protocol Buffers, which already has implementations in several languages. Initially, for desktop and mobile platforms as well as web applications, this protocol would just be used internally between components in the same application process. But I can dream about platforms themselves adopting the protocol someday. There would have to be glue layers between cross-platform providers and platform-specific clients, but if we design this right, the glue could be kept pretty thin, with most of the complexity being kept on one side or the other, so we don't have a multiplication of effort for n toolkits or applications on m platforms.
I think the protocol should be push-based, rather than pull-based like Windows UI Automation and some other accessibility APIs. That is, the application/toolkit would push full information about objects in the accessibility tree when it first creates that tree, and incremental updates when objects are created or destroyed, when properties change, when text content changes, etc. That's probably the only thing that's going to work for the web platform, and I think it's a model that other platforms would do well to adopt. (It's probably too late for Windows, but I dream of replacing the current accessibility model on desktop Linux someday, after my non-compete with Microsoft expires.) The challenge with a push model is making it efficient; we don't want to re-push the whole contents of a large text box when the user types a single character, and when we do need to push all contents, we need to do so efficiently. And sometimes we really do need to push a lot of information. For example, for a text box, we need the screen coordinates of every character, plus all of the boundaries between words.
Luckily, a push-based accessibility architecture has been done before, internally in the Chromium browser engine. As you probably know, Chromium has a multi-process model, where web pages are rendered in sandboxed processes, which communicate with a master browser process that interfaces with the OS. The browser process is not allowed to do blocking IPC requests into the renderer processes, so it can't implement synchronous, pull-based accessibility APIs like UIA in the obvious way. So the Chromium team implemented a protocol where the renderer processes push their accessibility trees, and incremental updates to those trees, over to the browser process, which can then store the trees in memory and then provide information to UIA or other APIs on request. The pushed trees are comprehensive, including the information I mentioned about text. Chromium does this using its own binary protocol called Mojo, which is kind of like Protocol Buffers but strongly tied to Chromium. So, while I'll take design inspiration from Chromium, I probably won't take the actual protocol or code.
I also want my protocol to scale down to embedded platforms. Accessibility on devices running embedded software (i.e. not Windows or another general-purpose OS) is basically an unsolved problem; as far as I know, device makers have to implement their own custom self-voicing interfaces, if they do anything about the problem at all. But imagine a standard where a user can pull out their smartphone, connect to the specialized device over Bluetooth or WiFi, and get an accessible interface to the device on their phone. Yeah, I'm swinging for the fence with this project. To pull this off, I think the protocol would need to be not only push-based but streaming, allowing providers to send out accessibility information without having to build up and maintain much extra state in memory. This would also help with the immediate-mode GUIs that are used in some games and game development tools. If we design the protocol right, these immediate-mode toolkits should be able to push out accessibility information and events at the same time that they're making OpenGL (or similar) calls to draw the current frame, again without having to hold much extra state in memory, which is something that these toolkits try to avoid.
I've been thinking of something very similar to this and have been working on the implementations. I currently have front-ends written in Java (Swing and SWT), Pascal (Delphi VCL, Delphi FMX, Lazarus LCL), C++ (wxWidgets and Gtk). I also have a HTML/JS prototype. I have backends written in Java, C#, Go, Crystal, and Nim. For the protocol I'm using JSON via HTTP. The more I work with this approach the more advantages I see. I think you're on to something.
Based on the set of front-ends, it sounds like the goal of your project is a cross-language GUI toolkit wrapper. Is that correct? The goal of my project is a cross-platform and cross-language accessibility abstraction.
That seems like it could be interesting. It sounds like you would need to have part of a library store and diff the tree state, and then send updates based on that? You could use that part for immediate mode GUIs, and then retained mode GUIs could skip it and maintain their own trees, and just deal with the protocol, maybe even the raw protobuf bindings or whatever it is you choose.
The Linux desktop environments could really use more people working on the accessibility stack, it's really outdated at the moment.
The Linux desktop environments could really use more people working on the accessibility stack, it's really outdated at the moment.
You can use d-bus on Mac, windows and Linux.
Apple's accessibility is excellent if you use their GUI library. Windows is good and improving.
I'm not positive what you want them to provide-- some kind of "fake GUI?" I might not be imaginative enough, but I can't imagine how that would work.
I'm not positive what you want them to provide-- some kind of "fake GUI?" I might not be imaginative enough, but I can't imagine how that would work.
This gets brought up pretty much every time immediate mode GUIs are discussed on HN. I think your comment is reasonable, and I don't disagree, but I also think it's important to not throw the baby out with the bathwater and dismiss immediate mode GUIs for accessibility reasons.
It's not at all clear to me that the right approach is to have both the accessibility interface and the GUI be generated from the same components. It seems to me that it's just approaching the lowest common denominator of a passable GUI and a passable accessibility interface.
The traditional widget-style GUI paradigm asks you to essentially copy all your application data into their format and to keep this format in sync with your own data. This is tedious, and I believe hinders the creation of better GUIs. On the flip-side, owning your data structure means it can indeed hook into the accessibility API for you.
Immediate mode GUIs provide an alternative approach, where they only handle rendering stuff on screen. Since all the data structures are now properly controlled by the programmer, it is much easier to create dynamic GUIs. Taking a step back like this provides an opportunity to further the state of the art.
The solution I see to providing accessibility in immediate mode GUIs is that the programmer has to hook into the accessibility API themselves -- if it makes sense. It's not clear to me that certain advanced GUI programs can ever be very accessible. Yes, this is more work, but there's also an opportunity to create richer experiences for people with disabilities.
It's not at all clear to me that the right approach is to have both the accessibility interface and the GUI be generated from the same components. It seems to me that it's just approaching the lowest common denominator of a passable GUI and a passable accessibility interface.
The traditional widget-style GUI paradigm asks you to essentially copy all your application data into their format and to keep this format in sync with your own data. This is tedious, and I believe hinders the creation of better GUIs. On the flip-side, owning your data structure means it can indeed hook into the accessibility API for you.
Immediate mode GUIs provide an alternative approach, where they only handle rendering stuff on screen. Since all the data structures are now properly controlled by the programmer, it is much easier to create dynamic GUIs. Taking a step back like this provides an opportunity to further the state of the art.
The solution I see to providing accessibility in immediate mode GUIs is that the programmer has to hook into the accessibility API themselves -- if it makes sense. It's not clear to me that certain advanced GUI programs can ever be very accessible. Yes, this is more work, but there's also an opportunity to create richer experiences for people with disabilities.
> This gets brought up pretty much every time immediate mode GUIs are discussed on HN. I think your comment is reasonable, and I don't disagree, but I also think it's important to not throw the baby out with the bathwater and dismiss immediate mode GUIs for accessibility reasons.
I can only talk about my own motivation for repeatedly bringing this up. If a developer is unaware that they're choosing an inaccessible GUI toolkit for their application, and that application is then required for a particular job, then that developer may end up unwittingly preventing some people from doing that job. And this isn't just hypothetical for me; I know of a blind person who lost his job (luckily only temporarily) because of an inaccessible application. So I think it's entirely reasonable for an application developer to dismiss a GUI toolkit because it's inaccessible. I wish more developers would research this on their own before choosing a toolkit for their applications. But since many don't, I feel obligated to draw attention to it. I'm glad I'm not the only one.
As for your suggestion that applications should implement the platform accessibility APIs themselves: First, it's impractical to expect application-level code to do this directly. The Windows accessibility APIs are notoriously hard to implement correctly. And my understanding is that the Mac, iOS, and Android accessibility APIs are only easy to implement if the application is written in the platform's native programming language. Now, these problems could be solved with an open-source wrapper library -- the SDL or GLFW of accessibility. And I'm planning to implement such a library myself sometime. But my plan is for that library to be used by toolkits, not applications. Because if every application has to directly implement accessibility in parallel with its GUI, then it's a safe bet that even fewer applications will be accessible. We want to get to a place where as many applications as possible can be accessible by default, with minimal effort on the part of the application developers.
I can only talk about my own motivation for repeatedly bringing this up. If a developer is unaware that they're choosing an inaccessible GUI toolkit for their application, and that application is then required for a particular job, then that developer may end up unwittingly preventing some people from doing that job. And this isn't just hypothetical for me; I know of a blind person who lost his job (luckily only temporarily) because of an inaccessible application. So I think it's entirely reasonable for an application developer to dismiss a GUI toolkit because it's inaccessible. I wish more developers would research this on their own before choosing a toolkit for their applications. But since many don't, I feel obligated to draw attention to it. I'm glad I'm not the only one.
As for your suggestion that applications should implement the platform accessibility APIs themselves: First, it's impractical to expect application-level code to do this directly. The Windows accessibility APIs are notoriously hard to implement correctly. And my understanding is that the Mac, iOS, and Android accessibility APIs are only easy to implement if the application is written in the platform's native programming language. Now, these problems could be solved with an open-source wrapper library -- the SDL or GLFW of accessibility. And I'm planning to implement such a library myself sometime. But my plan is for that library to be used by toolkits, not applications. Because if every application has to directly implement accessibility in parallel with its GUI, then it's a safe bet that even fewer applications will be accessible. We want to get to a place where as many applications as possible can be accessible by default, with minimal effort on the part of the application developers.
I think there's a difference between asking applications to implement the accessibility APIs themselves and asking applications to use accessibility APIs provided by the OS.
A graphics application should be able to submit draw calls or queues to a OS subsystem that, for example, generates a comparable audio space, performs colorspace/size transformations for improving visibility, etc. Developers should just be responsible for plugging in to these systems, and the systems themselves should be as standardized as OpenGL, Vulkan, DirectX.
A graphics application should be able to submit draw calls or queues to a OS subsystem that, for example, generates a comparable audio space, performs colorspace/size transformations for improving visibility, etc. Developers should just be responsible for plugging in to these systems, and the systems themselves should be as standardized as OpenGL, Vulkan, DirectX.
Applications don't have to implement this, the toolkit is supposed to handle it. It happens at the layer above Vulkan/DirectX, because those APIs are too low level and don't know anything window controls, text, etc. When applications disregard the platform's toolkit and use another toolkit that is not at feature parity with the one provided by the platform, they'll lose functionality. That's always been the case.
What I'm saying is that there should be a cross-platform standard like Vulkan or like the Document Object Model for accessibility. Toolkits should use implementations of that standard to enable accessibility like they use implementations of Vulkan or OpenGL to render graphics. In turn, applications should use the toolkits, as you've said.
I don't know if there is a "Khronos Group" for Accessibility Standards. Maybe there is.
I don't know if there is a "Khronos Group" for Accessibility Standards. Maybe there is.
IMO the closest thing to that is WAI-ARIA, the concepts apply anywhere.
I think you're right. Unfortunately, that isn't very helpful for developers not using the web platform.
I know people who use XCode through accessibility on Macs, and tell me it works well. Site, some things (3d graphics) are going to be hard to ever make accessable, but what exists is fairly good, if you just standard widgets. Blind people are using Macs and iPhones, and finding them highly effective.
I suspect most Devs would never link up and keep up to date an alternative accessibility interface. Also there is a lot of benefit to the accessable and standard interface being close, to make it easy to cooperate.
I suspect most Devs would never link up and keep up to date an alternative accessibility interface. Also there is a lot of benefit to the accessable and standard interface being close, to make it easy to cooperate.
It gets brought up because, at least from my perspective, none of the immediate mode toolkits are addressing this. I understand the desire to keep the code simple and only handle the rendering, but that is fundamentally opposed to the way some assistive technologies work. They need to access the UI as a state tree to even make sense. If the goal with these toolkits is to always avoid storing state information, that isn't ever going to work with screen readers. You can't push this task to the app developer, it really needs to be tied to the toolkit's internal hierarchy and focus handling.
My opinion for the last several years has been, if you use these toolkits, you might just have to accept that your app is not going to be accessible and is not really suitable for anything beyond highly specialized use.
My opinion for the last several years has been, if you use these toolkits, you might just have to accept that your app is not going to be accessible and is not really suitable for anything beyond highly specialized use.
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
The 'looks native' thing is mostly noise
https://news.ycombinator.com/item?id=26212787
The same valid comment was made when nuklear was discussed a few months back.
Many would love to unshackle themselves from the limitations of working with UI toolkits and it’s increasingly difficult/impossible to fulfill all the requirements we place on software, especially for solo developers. I don’t know how many one off tools I’ve written where the only interface is the command line over the years. It would be nice to have a simple step up from that as offered by Imgui tools.
The same valid comment was made when nuklear was discussed a few months back.
Many would love to unshackle themselves from the limitations of working with UI toolkits and it’s increasingly difficult/impossible to fulfill all the requirements we place on software, especially for solo developers. I don’t know how many one off tools I’ve written where the only interface is the command line over the years. It would be nice to have a simple step up from that as offered by Imgui tools.
As someone who occasionally writes tiny tools with some GUI, how can I test how well they work with accessibility tools?
On Windows, test it with NVDA[1] or JAWS[2]. On Linux, in Gnome, there's a screen reader that can be enabled in the settings under accessibility. I'm not sure what there is for Mac, Android, or iOS offhand.
Also, test in high contrast modes, and screen magnifiers.
1. https://www.nvaccess.org/
2. https://www.freedomscientific.com/products/software/jaws/
Also, test in high contrast modes, and screen magnifiers.
1. https://www.nvaccess.org/
2. https://www.freedomscientific.com/products/software/jaws/
To expand on this:
Windows also has the Narrator screen reader built in, and in Windows 10, Narrator is a decent screen reader IMO. (Disclosure: I used to be on the Windows accessibility team at Microsoft, where I worked on Narrator.) To enable Narrator, press Ctrl+Win+Enter. Narrator has a built-in tutorial (not written by me) to help you get started.
Mac and iOS has VoiceOver built in. To enable it on Mac, press Command+F5. On iOS, you may be able to triple-press the home button, on devices that have one. Failing that, you can find it in Settings.
Android has TalkBack built in. You can find it somewhere in Settings; the specifics are device-dependent.
Windows also has the Narrator screen reader built in, and in Windows 10, Narrator is a decent screen reader IMO. (Disclosure: I used to be on the Windows accessibility team at Microsoft, where I worked on Narrator.) To enable Narrator, press Ctrl+Win+Enter. Narrator has a built-in tutorial (not written by me) to help you get started.
Mac and iOS has VoiceOver built in. To enable it on Mac, press Command+F5. On iOS, you may be able to triple-press the home button, on devices that have one. Failing that, you can find it in Settings.
Android has TalkBack built in. You can find it somewhere in Settings; the specifics are device-dependent.
Thank you, that's very helpful! I'll be saving these for later :)
Hacky/Unixy solution: Make a CLI version.
As a front-end web developer who's looking to get into lower-level UI tech, I'm really curious to learn more about this. So novice question - what's the connection between immediate mode/openGL implementations and accessibility?
There's no reason in principle why an OpenGL-based GUI must be inaccessible. Qt heavily uses OpenGL, at least on some platforms, but is still more or less accessible.
It's more accurate to say that the vast majority of GUI toolkits that have ever been written are inaccessible, and most OpenGL-based toolkits fall into this category. Accessibility is tedious to implement at the toolkit level, especially in a cross-platform toolkit, so generally only big toolkits with corporate backing get it.
Also, on the web platform, if you abandon semantic HTML and use canvas or WebGL, then you're forfeiting the accessibility that your UI would normally have by default. As far as I know, the only way to make a canvas or WebGL-based UI accessible is to construct a parallel HTML DOM tree (and presumably use CSS to hide it behind the canvas).
Thanks for being curious about this.
It's more accurate to say that the vast majority of GUI toolkits that have ever been written are inaccessible, and most OpenGL-based toolkits fall into this category. Accessibility is tedious to implement at the toolkit level, especially in a cross-platform toolkit, so generally only big toolkits with corporate backing get it.
Also, on the web platform, if you abandon semantic HTML and use canvas or WebGL, then you're forfeiting the accessibility that your UI would normally have by default. As far as I know, the only way to make a canvas or WebGL-based UI accessible is to construct a parallel HTML DOM tree (and presumably use CSS to hide it behind the canvas).
Thanks for being curious about this.
It is very helpful for the developers if you could provide more info, such as error messages.
Ultimately browser as a gui, ( even without JavaScript ) will win, no other gui efforts are at par with that. So a WebKit with api to plug any language backend would be a good idea ( electron without js ). Is there any effort in that direction ?
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
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
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).
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).
Agreed. I always think I’ll one day build my own UI framework. Drawing to the screen and computing layouts is manageable, but then I think about the details: widget focus, text selection, platform keyboard shortcuts, text rendering (which encompasses things like right-to-left text rendering, ligatures, and a million other hateful complexities), etc and I realize why there are so few toolkits out there.
I do think it would be interesting to define a minimal set of user interface conventions that would forego a lot of features but would allow developers to stand a fighting chance of building a UI toolkit. If it became popular enough, users could come to understand its conventions even if they aren’t platform native (not ideal, but something has to change).
I do think it would be interesting to define a minimal set of user interface conventions that would forego a lot of features but would allow developers to stand a fighting chance of building a UI toolkit. If it became popular enough, users could come to understand its conventions even if they aren’t platform native (not ideal, but something has to change).
Something a lot of people re implementing GUI toolkits on OSX might not realize is that emacs/readline shortcuts work in all of the textfields (since ctrl is more or less "free" thanks to the command key.) IMO the GUI toolkit is one of those things OSX got really right and if you're not going to bother using it you might as well just target X11 and save yourself the trouble of putting effort into your OSX port.
The bindings are also customizable in `~/Library/KeyBindings/DefaultKeyBinding.dict`.
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.
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.
I tried it on Firefox Android, the text I write doesn't appear until I close the keyboard or press space. It is also extremely slow, like 5 FPS slow, scrolling is painful and the ripple animation in buttons lags too much. Long press to select text doesn't work, double tap selects a single word but doesn't use the native selection that gives me two handles to select more text to the left or right, the navigation keys on the keyboard are all disabled and so are the select and copy buttons. Line splitting is a mess and not properly done, here's a screenshot of some of the issues https://i.imgur.com/ApHDGuQ.jpg
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.
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.
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.
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/k...), but for instance Dear ImGui examples (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?
Has anybody carried out a larger traditional (i.e. non 3D focussed) application with an immediate mode GUI toolkit?
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.
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.
> 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.
I suspect it has more to do with the sheer amount of effort to build a new UI toolkit (text rendering itself is an insane amount of work) and so very few UI toolkits actually make it to a usable MVP whether they are traditional/widget-based or reactive.
I suspect it has more to do with the sheer amount of effort to build a new UI toolkit (text rendering itself is an insane amount of work) and so very few UI toolkits actually make it to a usable MVP whether they are traditional/widget-based or reactive.
I think the classic OSS community will be a bad starting point for this just for this reason, you either start by booting off GTK/QT and end up with a bloated monstrosity that many hardcore C++ developers from other domains will bypass or start from scratch and struggle with basics like text-rendering that you mention.
As someone coming from gamedev, I'd prefer something like this to be few files (maybe even single-file-header lib) that mostly wraps win32,osX,etc core API's for a native experience with good accessibility,etc support. My declarative-style experiment was maybe 6-7 files medium sized files (and I think the implementation ran away with C++ bloat and complexity trying to get the API to mesh updates with C++)
As someone coming from gamedev, I'd prefer something like this to be few files (maybe even single-file-header lib) that mostly wraps win32,osX,etc core API's for a native experience with good accessibility,etc support. My declarative-style experiment was maybe 6-7 files medium sized files (and I think the implementation ran away with C++ bloat and complexity trying to get the API to mesh updates with C++)
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/
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).
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).
My comment was written from seeing that experiment but also implemented an experiment for a React style declarative API over Win32 earlier and realizing how bad developer ergonomics became together with realizing doing it how close it is to an imgui flow.
Still the fact is that this is the only one I know of and in general accessibility hasn't been a big concern so far (And the imgui name isn't an accident considering the history).
Anyhow considering how laborious "modern" API's like UWP is, how badly declarative API's continue to map to C++ and the frequency at which gamedev rooted developers are asking for how to do "native UI"'s in C++ the time is definitely ripe for a serious one to emerge, the question is though if there will be one with enough momentum to become truly useful or if we'll end up with a bunch of small hacks that kinda covers some bases but don't end up being a good option for the majority.
Still the fact is that this is the only one I know of and in general accessibility hasn't been a big concern so far (And the imgui name isn't an accident considering the history).
Anyhow considering how laborious "modern" API's like UWP is, how badly declarative API's continue to map to C++ and the frequency at which gamedev rooted developers are asking for how to do "native UI"'s in C++ the time is definitely ripe for a serious one to emerge, the question is though if there will be one with enough momentum to become truly useful or if we'll end up with a bunch of small hacks that kinda covers some bases but don't end up being a good option for the majority.
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
[deleted]
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...
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.
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.
On the not 100% native side there’s Fyne which seems to only depend on xorg development headers. It can do a lot.
Are there any more resources about immediate-mode GUI compared to retained-mode? I've read 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?
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/imguiShould 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/
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.
Is there a tool that allows for checking such name clashes, ideally by specifying the domain to see how close you are?
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 (completely different field and name, but still can be found).
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.
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.
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.
Yeah, normally I wouldn't care about name clashes for unrelated tools but since GIO is part of GTK and specifically for writing cross-platform GUIs I think it becomes confusing again.
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
Oh, it happens when you hit the transform checkbox.
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.
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.
It'll get there, with time, but for now I'd avoid it for anything serious.
Tinygo is a bit better in this regard.
&errors.errorString{s:"no support for OpenGL ES 3 nor EXT_sRGB"}
golang lacks the language facilities to implement GUIs in a concise manner. This is one place where inheritance makes things a lot easier.
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.
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.
That is a non-argument. I was clearly not speaking about the bare minimum, but about required in a practical sense. Have you looked at the Go gtk bindings? If not, do so! The Go bindings are way nicer than the original C interface, Gtk was designed for.
Gtk fundamentally has an object-oriented design. As it is based on pure C, it has its own thin object layer. However the "object oriented" features of Go blend much better with that design than the native C. Because you can build type hierarchies of structures and each structure type has methods.
I very much regret that Go hasn't made bigger headway into the UI space, but it is a chicken and and egg problem. You need UI bindings to write UI applications. In general, there isn't enough development happening, especially for Linux. And alas, too many new developments get lured into writing electron apps. And there are of course a lot of QT apps.
But in my eyes, Go+Gtk should be a great combination for the desktop, as the bindings have a nice API and Go is really approachable for newcomers - it was one of the design criteria to not have too high learning efforts. If anything, there could be more documentation on how to use Gtk. And so far, my Go+Gtk programs can be easily recompiled and run on the Mac :)
But in my eyes, Go+Gtk should be a great combination for the desktop, as the bindings have a nice API and Go is really approachable for newcomers - it was one of the design criteria to not have too high learning efforts. If anything, there could be more documentation on how to use Gtk. And so far, my Go+Gtk programs can be easily recompiled and run on the Mac :)
> has failed to make headway into the UI space,
That's true (so far).
> and its language features make it very poor to work with for large code bases.
Not in my experience. We have quite a large codebase at work and we implement new features just fine. At least it looks better than in my previous C++ projects, where after a few years the code structure became a big rigid.
That's true (so far).
> and its language features make it very poor to work with for large code bases.
Not in my experience. We have quite a large codebase at work and we implement new features just fine. At least it looks better than in my previous C++ projects, where after a few years the code structure became a big rigid.
C++ is not really the benchmark to try to beat. There are superior languages for large code bases, but they're not "hip".
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.)
(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.)
> 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.
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.
It only failed because no one was willing to spend the money it requires to make it happen.
See how much money might already been spent into Flutter development.
See how much money might already been spent into Flutter development.
COM/UWP doesn't do class inheritance, only interfaces. It also provides delegation mechanisms.
Just like Win32 object model, is based on message dispatch across windows classes, not necessarly inheritance.
Just like game engines based on component architectures.
Just like Win32 object model, is based on message dispatch across windows classes, not necessarly inheritance.
Just like game engines based on component architectures.
It's in theory only a problem with Go interfacing with GUI libraries that are inheritance based, line Gnome. But I agree in general, GUI dev is one domain when inheritance becomes extremely useful in some cases, from a lib consumer perspective.
Other immediate-mode GUIs, like Dear ImGui, don't use and wouldn't benefit from inheritance.