As expected, same problem as all the other UI toolkits. Tried several of their apps, was able to use none of them with a screen reader or other accessibility tools. It's nice if you draw the UI directly to the screen, but you skip a lot of steps that OS vendors took to make sure your app can be used by as many people as possible. So always keep that in mind if you're going to use any of these GUI toolkits for your own project!
That's the hill that almost every new UI toolkit effort dies on.
If I were going to start one, I would actually start with accessibility. If everyone keeps tripping over the same thing, start by tackling that thing first.
Edit: it's occurred to me that an approach of starting with accessibility could also lead to an approach that degrades gracefully into text UIs (TUI) and command line usage and then scales all the way up to a GUI. That would be super interesting. Not sure it's ever been done.
I've been thinking about something similar. A polyvalent UI with CLI, GUI, and AUI (audible user interface). The AUI could be implemented as a TUI/HTML page (to leverage existing work on screen readers) but designed to be read rather than seen.
The behaviour based api that Fyne is designed with will degrade to a text UI, if anyone implements that driver ;).
I always thought I would but it’s never reached high on priorities…
Yea this is a big gap. It is planned but the task is huge. Once we have sufficient sponsorship or financial support in place you can be assured it will come.
Would you be willing to consider using a non-Go library via a C API for this? I'm working on AccessKit [1], a cross-platform abstraction over the various platform-specific accessibility APIs. It's written in Rust, and it doesn't yet have a C API, but that's planned. I'm aware that using cgo complicates build requirements, particularly on Windows, but it looks like you're already dependent on cgo on Windows (unlike, say, Gio).
[1]: https://github.com/AccessKit/accesskit I know I haven't yet done much with it this year. Hopefully I'll start doing substantial work on this again in the next few weeks. Threads like this one remind me that the world is waiting.
Please continue working on this. After years of work and having a novel backend infrastructure figured out for something that may have a lot of value for people, I have simultaneously been completely unsatisfied with frontend options — and I’ve tried nearly all of them. Accessibility is a major issue in almost all I tried, and closed source, vendor-specific UI options are not acceptable.
The main one I’ve been very interested in these days is called Makepad. Also written in Rust, still early in dev, but they need a lot of help on the accessibility front and their codebase is trying to do everything else. But the techniques are what I have been looking for in a UI kit. Anyway, I imagine there are a lot of cases like theirs.
The main issue is most of us do not have these accessibility issues. That domain knowledge needs to be collected and distilled into a framework that is open & simply covers most cases by its inclusion. Many JS frameworks have a lot of care in this regard, but their performance and dep hell make me want to avoid them (however tempting their ease of use may be).
Long story shot: this is very much needed and when I have time I would be willing to contribute.
Rust derive macros would be very powerful with implementing accessibility features.
No. Swing does not suffer from that problem because Sun actually cared about accessibility requirements back in the days, in fact, the only reason there's a desktop on Linux that has decent accessibility, Gnome (through the Orca screen reader and gtk accessility libs) comes from Sun's interest in having an accessible desktop for Solaris. KDE's track record is miserable in comparison to Gnome. Sun provided much of the funding for the initial efforts in making an accessible desktop.
Qt is partially accessible, in practice, it doesn't work well.
In case you're wondering, I've recently compared Go desktop GUI options[1], and there is also a new contender with new bindings to IUP[2]. The bottomline of my post is that Giu and Gio are good for small applications, Fyne is only okay for mobile platforms, and otherwise you should use either IUP (lightweight) or Gtk4 or Qt for full desktop apps.
I think it looks rather nice, and could be used for an Oberon like inspired experience.
Although since Go plugins support is stagnant, probably some kind of OOP IPC like D-Bus or gRPC, could be used for the concept of commands, viewers, gadgets and REPL.
I guess most figure it is easier than creating their own design language as that is tremendously difficult (for engineers ;) ).
Most figure if it is good enough for Android (and simile enough to Win10 and much modern iOS) it’s probably good enough for us.
I feel like the repo is a better starting point. Mobile support is pretty cool! I also saw some demo of it running over the web in-browser, Blazor style, but I'm not sure where that's at these days.
Yeah just install the latest helper (`go install fyne.io/fyne/v2/cmd/fyne@latest`) and run “fyne serve”.
Your Fyne app will load in a browser via WASM or GopherJS (depending on browser).
I explored couple of methods to develope desktop/mobile GUI with Go a few weeks ago. These are some of them:
1) Fyne (https://github.com/fyne-io/fyne)
Popular. Native functionalities like trays, etc. Mobile app possible. Looks okay.
2) Gio (https://gioui.org/)
Looks okay. Customisable. Tailscale Mobile app is made with this.
3) Wails (https://github.com/wailsapp/wails)
Easy WebView for Go.
Lacks native functionalities.
4) Sciter (https://sciter.com) embedded in Go
Haven't explored much.
5) Giu (https://github.com/AllenDang/giu)
Based on Dear ImGui. Doesn't look very polished.
P.S. I settled on Gio for the mobile app and ditched the desktop app altogether.
Now that I'm poking harder at the mobile Tailscale app, the seams are starting to show. When I open the three-dots menu, it opens instantly without an animation. Tapping and dragging my finger off a menu item triggers it anyway, and tapping the "Expires" text at the top of the menu closes it the moment my finger lands (rather than when I release, or leaving the menu open).
All the GTK4 apps I know all exclusive to their specific platforms. Most of them are being made exclusively for GNOME. Some of them have been made exclusively for elementary. I'm not interested if it's technically possible to create DE and WM neutral GTK4 apps. I'm interested if neutral apps are being made, which they aren't, whatever the reasons may be.
I doubt it's a good choice for cross DE and WM apps on Linux, let alone cross platform apps.
Same. I encourage the project to get some UI / graphic designers on board, and do what they say.
I mean, even just looking at the web site the spacing is odd, the animations are a bit all over the place, and it just looks slapped together. That kind of thing is totally cool for a cli tech product, but for something specifically supposed to be UI based…
And the product screen shots have similar issues.
Doing this stuff is very difficult so no shade intended - I’d love a de facto, nice looking, non cgo Go widget library. I wish them great success.
I agree, though it's not as bad as something like FLTK. Also if you're writing Go there are basically no alternatives.
Still, kind of boggles my mind why some GUI toolkit authors put so much effort into a project but don't do the relatively small amount of work to make it look nice so people will actually want to use it.
It wouldn't take much more than fixing the margins and padding to be honest.
I had a look at most apps built with it and I think it's perfectly fine. There was a lot of variability in how the widgets were used and styled so if something looks bad, I wouldn't attribute it to the library.
Literally any clear and well defined UI API in 'Go' would be 'modern' relative to the arcane, byzantine messes that are out there.
Even QT, a C++ standard is quite complicated. Android/Java is a bit bloated though workable. Flutter is 'modern' but quite opinionated and quite complex for what it needs to be.
What is complicated about Qt ? You have widgets and events(called signals) , you have clear way to do layouts and powerful ways to extend things. My only complaint is not about the API but is abut C++, when I was working with Qt4 there were not good official or unofficial but stable bindings to memory managed languages.
So personally for a quick side project I don't want to use c++, since is a side project some ugly and slow Electron app will be good enough and if I were on Windows I will probably do a C# Windows form app , or a Java Swing app.
You would use QML, which is quite similar to JavaScript, alongside the quite nice designer tooling, while implementing in C++ the code that needs high performance.
Additionally QML also gets compiled to native code anyway.
Although on Windows only apps, I would also use C#.
Java Swing is nice (yep I own the Filthy Rich Clients book), however it is basically stagnant since Java 8, minus bug fixes, HiDPI and Metal backend.
The UI part is not the issue, if you decide to use Qt you still need to do your "business" logic in c++ , then eventually you get some memory leak and have to setup tools to investigate what is the issue.
What would be a great feature for Qt is to have a way to make the GUI with QML but implement your actual work in C#,python,Java. So you would need a way to connect the GUI with data types and functions from this languages.
I remember Qt company tried at one point to offer Java,C#, Python official bindings but that effort failed, is probably hard.
Maybe an alternative to electron would be a JVM based modern GUI framework, something maybe inspired from the best parts of WPF, MXML and QML. And I am thinking JVM because you have access to Java's big standard library to do desktop like things like file,network IO and also have access to the native OS if needed.
You can do the business logic in QML, that is the best practice nowadays. That is why it is a full blown language based on JavaScript.
Or do little helper classes that you than use from QML, just like those Python libraries that are mostly native code.
Qt also has official Python bindings nowadays, even though the others were dropped, due to lack of interest.
Don't forget automatic memory management can also have other kinds of leaks, and use similar tooling, to track down where references are wrongly being kept alive, e.g. Forms/WPF event handlers.
Once the project moves to push bindings I think you can see it’s admitting the language they picked is no longer fit for purpose :).
Go comes to the rescue here and Fyne is idiomatic Go so learning it is trivial!
There were always been bindings, but at the time I was working with Qt the quality was bad, if I were to start a project I don't want to use some automatic generated binding or some one man side project binding, I don't have time to spend in debugging bugs outside my code.
Except of Python are there other bindings you would bet your precious time on? Foe example I had a few hours side project, I needed a simple GUI to let the user slect soem folder and files, then the code logic would do the IO , do some transformetion and report to the user. Would I spend more time messing around with the bindings instead of writing the code ?
I know my example would be a perfect use for CLI but the target user was a Windows person that just REFUSED to accept the concept that they are competent person and could use a CLI app and paste a folder path in.
Yeah, when targeting desktop only workloads, given that they have hardly been updated for anything else, and it is actually one of the Qt 6 roadmap items to improve upon.
Everything in QT is non-trivia especially due to it's use of C++.
Signals themselves are a bit tricky, and frankly a kind bloat, in that they are yet another abstraction that is not actually needed.
Signals, which are related to the event loop and threading, create a bunch of potential issues that can't really raise their ugly heads in JS/Python, and even in a multi-threaded language like Java are a bit easier to deal with.
QML is quite good for a narrow range of things, but if you start to go outside the bounds of what it was intended for it goes of the rails. You still need to know C++ for builds, and, C++ integration doesn't work particularly well.
IDEs do not refactor well in C++, don't pick up as many errors, cmake is weird.
QT has some amazing things (collections) that without, frankly, I don't think I would even use C++, but they all come with hints of weirdness.
QT written today, for a narrow platform, in a single language, hopefully more modern - would be something different.
The paradigm of qt is good, the code is cryptic when you are a beginner. It uses too much concepts that people wouldn't necessarily be used to. If you read the code there would be many lines where you just tell "what is this?".
Too fresh. While it looks nice, it's not yet usable for anything but very simple mobile apps. I'm not actually quite sure whether it will ever be suitable for complex desktop applications; at least for now everything is clearly designed only for mobile.
Will Fyne run on a Raspberry Pi Zero without a desktop environment? e.g. fullscreen with no other distractions other than the app? I'm making a touchscreen interface and I'd like something to boot directly into a UI with no other OS visible on screen...
No, that's not possible. Not only that, Fyne makes some questionable layout choices in conflict with platform UX guidelines. For example, it insists on underlining multiline text edit fields to indicate focus, which looks horrible and confuses users.
Or doesn’t use OS components on any platform. Having a theme that makes them look similar is at best uncanny valley and at worst a huge waste of time for toolkit and developers.
Every OS version update tweaks the design I’m an attempt to look new or unique - try to do that across the 5 or more desktop and 3 mobile OS UIs that it supports and you’ll see how every year it would be a full time job just adapting to those trends.
It depends on your definition. It installs and runs as native with the speed expected because it is compiled for the platform.
It does not use the OS UI components for forms/buttons, but many built-in apps don’t even do that now so the definition is kindof changing I feel.
I really tried to develop several cross platform GUI apps in Go, using various frameworks. The result was far from satisfactory. My advice: don’t bother, just use Qt. Or Electron if you can stand the resource usage. Or maybe Flutter, I have no experience with that; maybe I should give it a try.
Qt and Electron are horrible options. What makes modern GUIs so complex that nobody's able to come up with a viable alternative that's simpler, faster and smaller? Whenever I talk to video game programmers, they scoff at the idea that UI is a difficult problem to solve. And they're right. They can get a computer to draw hundreds of complex 3d objects 120 times a second. Why can't we draw some text and a box 60 times a second so my window doesn't skip when I scroll?
Just for font rendering you need harfbuzz+freetype if you want something decent (e.g not stb_truetype) so you're already talking 5-8 mb of libraries at the bare minimum. You also want ICU for proper unicode processing unless you don't have any unicode string operation anywhere in your software . +16 mb and we haven't rendered a single pixel. Then you're making a GUI - you aren't going to restrict it to people with a GeForce RTX1070+ right ? No, you want everyone to be able to use it, yes, including that one person in the back with a GMA500 intel chipset which does not support opengl 3.2 but will leave an absolutely scathing review of your app if it does not work on their machine (alternative: same thing but it's the company you're building the software for which had a fleet of 2008 dell Inspiron for their employees). So now you need to ship ANGLE + some software opengl implementation so that people with 2008 eeePCs won't see a black square when they open your app. Add 10 or so more megabytes and you have the very, very, very bare minimum on which to start building your UI toolkit if you want to cover common use cases.
These are valid points, I'm currently going through the dance of building a custom cross platform gui for mobilde+desktop tailored to my application. Proper localized text rendering is hard, Harfbuzz and Freetype are solid options to start with and are available on recent Linux desktops. I've abstracted the text rendering to replace Harfbuzz and Freetype with platform native libraries on Apple and Windows.
The renderer itself is abstracted and defaults to opengl 3.3 with a fallback to software rendering as last resort and to be portable.
Long story short: It's not easy but very possible to build a polished cross-platform GUI smaller than 1MB. My app binary currently compiles down to 135 KB on desktop, in the end I aim for less than 2 MB for the whole application.
However I wouldn't recommend this for most applications where a framework would be a faster option for a traditional GUI.
> I've abstracted the text rendering to replace Harfbuzz and Freetype with platform native libraries on Apple and Windows.
I hope your UI designers are happy with some text wrapping on one platform and not another because they have slightly different metrics even given the same font - for me this has never flown and I had to work to make things pixel-perfect across mac / windows / linux a few times now which definitely does not work when using the platform renderers.
This is dynamically linked to all those libraries which must be installed. One of the points above is how small can you be without those dependencies.
All Fyne apps need is a working graphics driver capable of OpenGL spec from 2011.
Fyne manages to be below 10MB for a stand-alone application. A future release where we add more complete language support might have to be 12.5MB entry point sadly, but it’s still small by modern app standards.
Everything you just described takes work, but it isn't difficult. Applications both desktop and mobile have been doing all of that for decades now. Why hasn't somebody in the Go community managed it at some point in the past 10 years?
Just try to use one of the minimal frameworks (which are usually also immature, buggy and poorly documented, especially in the Go GUI ecosystem, but that’s beside the point). Unless you’re developing something trivial or you’re the type who love to implement widgets from scratch and don’t give a crap about OS-level consistency, ten minutes in you’ll wish you have access to some standard OS widget that’s not implemented, and thirty minutes in you’ll wish you have one of the more complex widgets in Qt at your disposal. Most of us just want to make a damn app, not a widget library from scratch.
What do you think your screen is doing all the time? You can't blit to the screen once and then "freeze" it. Your computer/phone is blitting pixels all the time.
Most games are immediate mode graphics. An operating system cannot function efficiently if its graphics are not more like a retained mode system. There’s a big difference between the two.
The point of the GP argument is that the lack of decent cross-platform GUI libraries is astounding to game programmers because games are much more difficult and involved than GUIs yet producing a game that runs on multiple platforms is mostly a solved problem.
The point is not to say "Why don't you guys do GUIs like games where you recompute the whole thing every frame?". Even the people who talk about immediate mode GUI are talking about the API of defining the UI, not the implementation details. It's perfectly consistent to have a GUI library that exposes an immediate mode API but retains a lot of state between frames and only does repainting when necessary.
Also I find this talk about battery life in general disingenious given that more and more tech companies are converging on implementing applications in Electron which drains battery life very quickly.
There was a post on HN where someone explored the immediate gui paradigm for their PhD (or masters degree, don't remember) and they discovered that this assumption is actually incorrect, given the interactions and os optimizations the battery usage (well, cpu usage and gpu usage) was lower overall. I remember very little details, it was amazing
I would have to read it to see what you mean. I cannot imagine a world in which the normal way of doing immediate mode graphics was more efficient than retained mode.
I'm trying hard to find the link, but I'm struggling, sorry.
During my researching, a lot of posts point out that "innediate mode" refers to the API, not the implementation, and that React is effectively a hack to obtain an immediate mode gui on top of retained mode.
Doesn't say anything about performance, just that the implementation behind the scene can retain state to save battery
Video game UIs exclude a lot of hard problems (e.g. accessibility, power use, cross-platform abstractions like I/O, many control types) simply by being embedded in a video game.
Video game UIs do (almost) everything you just mentioned.
Accessibility: I'm not well versed on accessibility.
Power Use: mobile games are a thing. I wouldn't be surprised to find out that, on average, mobile games use less battery than electron apps (excluding Unity games. Unity games are the Electron Apps for video games).
cross-platform abstractions like I/O: video games run on more platforms than most apps with a larger variety of I/O and control types.
Regardless, that wasn't my point. My point is that video games are doing much, much more than most desktop apps could ever dream of doing in terms of pure work, and yet things like complex UIs and cross-platform deployments aren't considered difficult problems.
> Accessibility: I'm not well versed on accessibility.
Lol, you’ve pretty much torpedoed any credibility right off the bat.
> Power Use: mobile games are a thing. I wouldn't be surprised to find out that, on average, mobile games use less battery than electron apps
This is a flawed take on multiple levels.
> Regardless, that wasn't my point. My point is that video games are doing much, much more than most desktop apps could ever dream of doing in terms of pure work
This is very hand wavy as to be meaningless. What is “pure work” and how does it have anything to do with architectural complexity? I think you underestimate a lot of of the complexity that goes into the underlying stack of components for desktop applications. If you hand wave away (text) layout, text rendering, accessibility and performance optimization - then you can claim anything.
As already mentioned UIs in games are typically much more limited in scope and complexity.
As a backend-now-fullstack dev, i can tell you mobile dev is actually harder than backend now.
At its beginning, mobile apps were just a few simple screens mostly querying a server.
It is now closer to the gigantic desktop apps of the 90s (because most have to work offline), except with a much higher quality UX, as well as deep OS interaction (check the list of iOS extensions), AND internet connectivity.
That's why you see things like agent-based concurrency arriving on swift, which is mainly a client-side language.
If you're truly interested in being enlightened then do the work. It's not up to internet strangers to refute your painfully uninformed assertions in detail. That's what education and work experience are for. You simply can't cover it in a comment.
I wrote my comment to make it clear for anyone else who doesn't work in this area that what you said is utterly wrong. HN typically has well informed comments so people take it a little more seriously than other places. The thread is also old enough now that no one except you will probably read it.
I'll at least give you something so that you're not left holding nothing but a mean internet comment.
First: If you were to rank the hardest technical challenges in modern computing then UI architecture is easily in the top 5, if not #1. In that same list you have distributed (as in networks) computing. It's an incredibly difficult problem with an endless pit of depth. UI IS HARD. If your next question is "what makes UI hard?" then - good! - you're curious. Take some courses or something. Try building a great UI for non trivial use cases. Educate yourself by doing!
Second: A computer drawing "hundreds of of complex 3d objects 120 times a second" has absolutely nothing to do with complexity of UI. The challenges in UI are not strictly a matter of drawing dots on the screen! The two things are orthogonal! Game engine renderers are solving a very constrained problem whereas UI architecture is totally unconstrained.
Third: Game GUIs have a TINY fraction of the UI components you'd need to support a sophisticated modern day business application (think Salesforce). Someone else mentioned accessibility but that's just the tip of the iceberg. The sheer number of UI components in business applications dwarfs what you see in games. Not only that but the UI components I'm talking about need to be assembled in an uncountable number of ways. And they're constantly being updated/tweaked.
-
There are many people who have devoted their entire life to finding a general purpose way to build great UI. No one has cracked it yet and it's not because people are stupid or don't want to. It's HARD. But also a lot of fun if it's something you enjoy doing.
The Windows API through Delphi was simple and fast 20 years ago. Although the exe would take 400 KB space, so for smaller tasks I would bypass Delphi's stuff and call the Windows functions directly, and create 50 KB sized apps. (the A functions. Guess the Unicode W functions would already double the space)
But on Linux there is no way around Qt. (or Gtk, but the recent Gnome versions are horrible)
Although you could just make the Windows exe and run it through Wine. That is so simple to develop, and for any bug you can blame Wine.
Nowadays I use Lazarus. It is supposed to take the old Delphi code and create a native Windows,Qt,Gtk version from it. For Windows, it creates 2MB exes. Considering that Delphi made smaller files, it must be filling 3/4 of the file with garbage. The Qt,Gtk versions somewhat work, though Wine would probably more reliable
A few weeks ago I read a series of tweets from someone who used a game engine (I think godot) to write a cross platform tool with a GUI with great success.
GitHub says Fyne has 120 contributors… and Fyne Labs is working to get substantial investment to secure the future like Google has done for Flutter or Facebook for react native.
TreeView is what I need too, and Fyne is (AFAICT) about the ONLY Go widget kit that includes one. And it is ugly too, but let's see what the Fyne 2.3.0 facelift brings :-D
