1. 39
  1.  

  2. 10

    I’m compelled to point out here that Gio doesn’t yet support platform accessibility APIs, meaning Gio-based applications are completely unusable for people who require tools such as screen readers. I don’t say this to criticize the Gio developers. I’ve already discussed the issue with them, and I believe they’re waiting on me to do the heavy lifting here, which I will. I just point this out so that developers that are thinking about using Gio in their applications will take this limitation into consideration when making their choice.

    1. 7

      [I do not have a hat for it, but am a Gio maintainer]

      Indeed, we do lack platform accessibility support right now. We’re grateful that you’re stepping up to tackle this problem generally, and I’m hoping to contribute directly to your efforts in the future.

      Platform accessibility support is a requirement before Gio 1.0. We definitely take the lack of it seriously.

    2. 3

      Most of these toolkits require GL and thus Cgo. It’s good that they exist, but sad that they’re dirty in this way.

      Though, the unikernel puzzles me.

      1. 4

        [I do not have a hat for it, but am a Gio maintainer]

        Yes, Gio does require GL and CGO for most platforms. On Windows it actually bypasses CGO, so you can cross compile a Gio application for windows from any other OS trivially. The requirement for CGO is less onerous than I expected it to be though. It’s been really easy to build and distribute Gio applications for all OSes in my experience.

        The unikernel was a demonstration that you can build special-purpose applications with GUIs easily. I think (though I’m having trouble remembering) that Elias’ goals there were both do demonstrate a way of sandboxing applications without running a whole virtualized OS, as well as a possible Kiosk-style deployment option. Looks like Elias talked about it during the First Community Call if you want to hear it from him.

        1. 2

          I’m still trying to figure out how I’m going to maintain the independence from cgo on Windows while incorporating my Rust-based AccessKit project. I don’t think reimplementing AccessKit in Go will be a reasonable solution, nor do I want to implement it solely in Go, as that would hinder adoption by code in other languages. And I do indeed want AccessKit to be used across multiple languages, so as not to spread accessibility efforts too thin. I’m not even sure that implementing UI Automation (the Windows accessibility API) in pure Go would be feasible anyway; UIA tends to make many calls into the COM interfaces implemented by the application, and we’d need to measure the current overhead of calling into Go from outside.

          I plan to provide a C ABI wrapper for AccessKit. So one option would be to compile that as a DLL, then call that DLL using Go’s syscall package. But that would require Gio users to distribute a DLL with their Windows applications, which they don’t have to do now. And if you make the DLL optional, you can bet that some developers will omit it, leading to inaccessible applications. I saw that happen when Qt implemented accessibility in a plugin. One of my goals with AccessKit is to eliminate as many excuses as possible for omitting accessibility, and make it impossible for downstream developers to turn off, including accidentally. So if we go with the DLL option, Gio would need to fail to run on Windows without that DLL, and I understand this may be unacceptable.

          Of course, one option is to simply require cgo on Windows. But that would require application developers to have a MinGW toolchain, which they don’t need now. That would lead to another excuse for omitting accessibility.

          Elias suggested that it might be possible to use a .syso file. But given that I’m going to be using Rust, it may require some elaborate toolchain hacking to produce a suitably self-contained .syso file. It would also likely require using a GNU toolchain, which AFAIK isn’t an option for Windows on ARM64. I don’t know if Gio is running on that combination of OS and architecture yet, but I know Go is.

          So I see no really good option right now.

        2. 1

          Is there a quick, obvious way to tell if a project requires cgo without having to grep the source or trying to build with cgo disabled? I’m allergic to cgo, and am often annoyed with how long it takes to figure out if an external thing needs it when I’m evaluating a long list of possible external things I might want to use.

        3. 2

          This is a good guide, and Gio is a nice GUI project. I like its sensibilities.