Fyne, a cross-platform GUI toolkit written in Go
fyne.io
fyne.io
[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.
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.
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.
(As in the easy-to-use kitchenware https://en.wikipedia.org/wiki/OXO_(kitchen_utensils_brand) "In June 2004, Helen of Troy Limited bought OXO housewares for $273.2 million.")
It's a general pattern, make your thing easy for old people and folks with disabilities and it's also easy for everybody else.
- - - -
Check out Elm's accessible-html module. Enforces accessibility at compile-time.
https://package.elm-lang.org/packages/tesk9/accessible-html/...
https://dev.to/nimmo/easier-paths-to-accessibility-in-elm-4o...
Qt and Swing have this problem?
Qt is partially accessible, in practice, it doesn't work well.
[1] https://slothblog.org/No_Good_Go_GUI.html [2] https://slothblog.org/IUP_for_GO.html
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.
Not the same, but could be approachable.
Anyway, nice work.
- Flat UI
- Lots of wasted space
- No clear distinction between element types
- Bland, lacking of color.
https://github.com/fyne-io/fyne
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.
I doubt it's a good choice for cross DE and WM apps on Linux, let alone cross platform apps.
https://fosdem.org/2022/schedule/event/mobile_adwaita/
https://thisweek.gnome.org/posts/2022/06/twig-46/
https://aplazas.pages.gitlab.gnome.org/blog/blog/2021/03/31/... (2021)
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.
go run github.com/fynelabs/notes@latestStill, 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.
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.
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.
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.
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.
For 99% who want to ship something and are not hipsters, QWidgets is enough.
Personally I don't even build QML
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.
And also tries to not be opionated; See for example their approach to navigation.
Further from a user perspective you can get very quickly complex UIs setup; faster than in any other cross platform framework that i have seen so far.
flutter doesnt seem to be overly complex to what it needs to do. It provides quite some value.
For making a specific range of mobile UI apps, actually it is pretty good.
But I would not use it for anything outside that range.
.NET MAUI is rather fresh. And it uses native controls on each platform.
But it would still be x11 or wayland underneath...it doesn't support direct Linux framebuffers.
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?
GitHub then Microsoft invested heavily into Electron. Tons followed. Not to mention the existing web ecosystem.
There are like two dozen random open source developers who bothered to work on Go GUI libraries, on the side.
It is objectively better than Javascript in many respects, not least of which is performance.
There are only two major blocking issues I see, and none of them is unsurmountable:
- Complex text layout (harfbuzz)
- Accessibility
Battery, for starters. If desktop UIs were all written like games, nobody would carry their laptops anywhere. Because they all be plugged in at home.
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.
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
You have no idea what you're talking about.
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.
https://medium.com/swlh/what-makes-godot-engine-great-for-ad...
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.
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.
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 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.
816K /usr/local/opt/freetype/lib/libfreetype.a
1.9M /usr/local/opt/harfbuzz/lib/libharfbuzz.a
2.1M /usr/local/opt/sdl2/lib/libSDL2.a
I don't think people really mind a 20MB executable if it was a self contained application with good performance and UI.
My favourite alternative is probably https://crates.io/crates/conrod-core
That said you generally want widgets that look native in your platform, not some gui that feels like it's been taken out of a videogame.
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.
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
Except Fyne and others… we have a full desktop well underway and some distros are shipping Fyne apps and/or FyneDesk!