Get the top HN stories in your inbox every day.
ClawsOnPaws
api
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.
carapace
Shout it from the hills: OXO!
(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...
mrlemke
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.
andydotxyz
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…
andydotxyz
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.
mwcampbell
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.
survirtual
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.
andydotxyz
Yes, we have actually considered AccessKit in our discussions :)
masukomi
thanks for this. saves me from wasting time on it.
ralls_ebfe
Thanks, I thought "maybe they implemented accessibility by now", but it seems to be a huge task.
danachow
> As expected, same problem as all the other UI toolkits.
Qt and Swing have this problem?
sbcd
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.
jonathanstrange
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.
[1] https://slothblog.org/No_Good_Go_GUI.html [2] https://slothblog.org/IUP_for_GO.html
Tozen
The problem with that is jumping around to the many different GUI toolkits, where many prefer or are trying to minimize the number.
jonathanstrange
The idea is that you choose the GUI toolkit that best suits your requirements, of course.
pjmlp
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.
Not the same, but could be approachable.
Anyway, nice work.
Aeolun
All of these are nice, but why do all of them use material design? That basically rules them out for me.
hsn915
Material design a disaster in terms of UI and UX.
- Flat UI
- Lots of wasted space
- No clear distinction between element types
- Bland, lacking of color.
danielvaughn
Agreed. I don't understand why designers like it so much. It's awful.
andydotxyz
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.
chakkepolja
I believe it has to do with mobile support. Material design works well on mobile.
password4321
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.
https://github.com/fyne-io/fyne
PhilippGille
Their web driver is in technical preview as per the v2.0.0 release notes: https://github.com/fyne-io/fyne/releases/tag/v2.2.0
andydotxyz
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).
kretaceous
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.
nyanpasu64
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).
socialdemocrat
Why not Gtk? It looks quite nice and has a great GUI designer. I used to do UI mock-ups with Glade just because I thought it was so well thought out.
_2paq
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.
Santosh83
Does GTK work for targetting mobile platforms, like your parent wanted?
3np
GTK4 libadwaita has first-class mobile.
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)
undefined
undefined
trentthethief
I really wanted to like it but the ui is very unappealing to me.
0x20cowboy
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.
ajwillia_ms
For v2.3.0 (next big release) we have a UI refresh done by a graphic designer. Very exciting :)
IshKebab
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.
syeare
I'd take a UI uglier than this and customize it rather than electron.js any day
httpsterio
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.
moondev
Looks like it's possible to provide a custom theme, curious if there are more examples of this
go run github.com/fynelabs/notes@latestundefined
jitl
What about this API makes it “modern”?
jollybean
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.
simion314
>Even QT, a C++ standard is quite complicated
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.
pjmlp
Nowadays that isn't the way to use Qt.
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.
jollybean
Everything about QT is complicated.
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.
rat9988
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?".
je42
Flutter tries to be declarative -
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.
jollybean
Flutter 'everything is a widget' and especially their needless obsession with statelessness, almost ruin the platform for me.
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.
DeathArrow
>arcane, byzantine messes that are out there
.NET MAUI is rather fresh. And it uses native controls on each platform.
juki
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.
davelondon
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...
tyingq
It appears to use glfw, so there's this: https://www.glfw.org/docs/3.3/window_guide.html#window_full_...
But it would still be x11 or wayland underneath...it doesn't support direct Linux framebuffers.
andydotxyz
We test on rPi4 but you will need X or Wayland to boot the graphics driver and run your fullscreen app at this time.
meling
Can Fyne be configured/themed to look like macOS Desktop app?
jonathanstrange
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.
andydotxyz
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.
madeofpalk
Is this a "native app"?
andydotxyz
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.
oefrha
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.
PainfullyNormal
> don’t bother, just use Qt. Or Electron...
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?
jcelerier
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.
cryo
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.
hsn915
I found the following file size for library files on my system:
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.
PainfullyNormal
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?
oefrha
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.
jb1991
> Why can't we draw some text and a box 60 times a second so my window doesn't skip when I scroll?
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.
hsn915
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.
Fire-Dragon-DoL
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
formerly_proven
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.
PainfullyNormal
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.
bsaul
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.
throwawaylala1
> Whenever I talk to video game programmers, they scoff at the idea that UI is a difficult problem to solve. And they're right.
You have no idea what you're talking about.
PainfullyNormal
Enlighten me, then.
benibela
Cross-platform is difficult
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
andydotxyz
> But on Linux there is no way around Qt. (or Gtk, but the recent Gnome versions are horrible)
Except Fyne and others… we have a full desktop well underway and some distros are shipping Fyne apps and/or FyneDesk!
omnibrain
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.
PainfullyNormal
Are you talking about this article[0]? That's interesting. I'll have to do some experiments with that. Thanks for sharing!
https://medium.com/swlh/what-makes-godot-engine-great-for-ad...
hsn915
I tried Qt but the result was the furthest thing from satisfactory. My advice: don't bother.
undefined
Get the top HN stories in your inbox every day.
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!