8 ms·

So you want to write a GUI framework (2021)

195 points by eatonphil 3y ago

eatonphil 3y ago
As I'm looking through the Skia APIs I have the dumb question: why doesn't Skia have its own wrappers for input method editors (at least on Windows and macOS)? Or maybe it does and I'm missing it. Implementing these APIs for Windows and macOS seem super arcane. It's hard to find docs on implementing them. I guess there must be a good reason there are not cross-platform libraries that abstract IME specifically.
- adamnemecek 3y ago
  Presumably to keep the focus of the library small.
  - eatonphil 3y ago
    I wasn't under the impression Skia had a focus on being particularly small. (Though I have no clue. I'm just getting into this stuff.)
    - adamnemecek 3y ago
      Check out nanovg and all the alternatives.
- sporedro 3y ago
  I can’t answer from rust perspective, but just my opinion. GUI frameworks in general seem like an atrocity, you have QT and that seems like it besides proper native development and targeting 1 platform. Java still seems like the only language with cross platform GUI and swing/awt are on the way out with javaFX being “abandoned”? (Probably not the right term but it never was made main stream). You got to Python, etc and it’s an absolute mess. C/c++ have a few but cross platform still seems tough. Don’t even get me started on the mess of electron.
  - chairhairair 3y ago
    You haven’t heard of Flutter?
    - brabel 3y ago
      Exactly... looks like most people don't know that Flutter uses Skia... and it's a real multi-platform framework (Windows, MacOS, Linux, Android, iOS, even Web), whether you like it or not.
  - giraffe_lady 3y ago
    What's interesting to me is that there are a handful of languages that include gui frameworks: tcl with tk, erlang binds wxwidgets, and racket has its own thing built on gtk. It's curious what these languages have in common too: as languages almost nothing. But they're all venerable, proven & respected in their domains if not beloved, and relatively unpopular. I don't know how to interpret that. Maybe it's just a coincidence. Or stdlib gui frameworks are just out of style and it's survivorship from the old ones. But then python is from around the same time, why doesn't it?
    - remexre 3y ago
      tkinter is the Python one!
      - vram22 3y ago
        Ruby has a Tk-based one too, but I don't remember the name, since I used it only a little, years ago, though I did some non-GUI Ruby and Rails web work.
        beeburrt 3y ago
        RubyMotion? http://www.rubymotion.com/ http://www.rubymotion.com/
        3y ago
- ReactiveJelly 3y ago
  Skia only does rendering, not input, right?
- c-smile 3y ago
  IME handling must be implemented at OS level. IME is not Skia's responsibility.
  - throwaway2037 3y ago
    IME handling must be implemented at OS level. Really? X11 has a wide variety of IMEs. That's user space, not "OS level" (kernel?). A different view: It might be possible to write an IME for X11 using Skia. :)
    - okanat 3y ago
      OS level includes the core system libraries in the userspace. Of course you can argue no such thing exist in Linux. It is the odd one among all OSes, both major and minor, in not providing any stable and well-defined system layer. The lack of unified standards in X11 and especially in Wayland/libinput is a huge source of problems in accessiblity and user experience of traditional Linux environments. Each of those IMEs (ibus, fctx,...) are a major pain to setup and configure correctly. They often don't look "native" to the toolkit of the desktop.
- TazeTSchnitzel 3y ago
  SDL2, which is an abstraction intended for games (gives you a window, sets up OpenGL and handles input events, but leaves the drawing to you), has a very simple text input API that can handle IMEs: https://wiki.libsdl.org/SDL2/SDL_StartTextInput https://wiki.libsdl.org/SDL2/SDL_StartTextInput + https://wiki.libsdl.org/SDL2/SDL_SetTextInputRect https://wiki.libsdl.org/SDL2/SDL_SetTextInputRect. But the trade-off is that you can't write a text editor with this. It just lets the user type text using the OS's text field or similar and the app is not in control while they do so.
Solvency 3y ago
I think the 3 absolute demons that will eventually seek to destroy you in any homebrewn GUI framework will eventually be: - Rendering and dealing with text in all of its extreme permutation. Styling. Localization. Character sets. Etc. - Modern accessibility standards. There are countless annoying yet de facto UX patterns that are just nightmarish to check off the list from scratch. Inputs/forms/etc. Even worse than accessibility, because you can decide to forgo that completely if you really wanted. The sheer volume of UX use cases and edge cases involved in even seemingly basic input components is also an exercise in rote dread. You've got input validation, error states, just so many ergonomics to deal with. - Fluid layouts and scaffolding. This is where modern HTML/CSS finally starts to shine because making flexible layouts is actually quite painless. But it's a motherfucker to roll your own approach.
- moron4hire 3y ago
  But you can't forgo accessibility. Anyone who would make software with your framework would be in violation of several laws. EDIT: I see that there are people down voting several comments in this thread in support of accessibility. I wonder what disagreement that you have? Surely it can't be "not a large enough market". There are more legally blind people in the world than Firefox users, yet web developers will happily test compatibility with that dying browser and eschew screen reader testing.
  - TheBrokenRail 3y ago
    Not a lawyer, but if this was true, wouldn't a bunch of developers and companies be facing fines? Especially smaller open-source stuff. And larger companies as well (for instance, Reddit's mobile app is infamously inaccessible).
    - moron4hire 3y ago
      Yes, they would. We're all only getting away with it because nobody has complained. It's a massive risk that companies are running. I don't know how Reddit has skirted it for so long, but there have been several high profile cases in recent years.
groby_b 3y ago
This is all a very neat summary, but I'll go out on a limb and say that for most of us, the first-order approximation should be "don't. Just don't". Been there. Done/sort of doing that. Have impressive collection of scars. There are no t-shirts to be had. This document only barely scratches the surface of the work necessary. If this is your calling, by all means, but expect to sink a good chunk of your life into it. Things are glossed over in a paragraph that mean years of work. (My favorite is the internationalization section, closing with "But don’t worry: there’s a standard. All you need to do is implement it." - All you need to do, indeed :) To be clear: Colin knows it's years of work. He's been working on a number of excellent projects in the space (xi-editor, druid, ...). But I really feel this deserves a warning sticker, lest you accidentally spend a decade or two of your life on it.
- ReactiveJelly 3y ago
  Eh, re-inventing wheels is fun. I learned a lot making my own games from scratch with no engine. I'll make a bad one-user GUI kit some day too.
- c-smile 3y ago
  Well, it is definitely not a suicide mission. At least in my Sciter I've implemented all those by myself in reasonable time frame - first version was made in 9 months. But "yes", you need some prior experience, in order to come up with flexible architecture that will allow to expand it further without major redesigns. First version had DOM/CSS and used just GDI. GPU support (Direct2D, OpenGL|Metal|Vulkan via Skia) was added later with API staying the same.
dang 3y ago
Discussed at the time: So you want to write a GUI framework - https://news.ycombinator.com/item?id=28127492 https://news.ycombinator.com/item?id=28127492 - Aug 2021 (173 comments)
smasher164 3y ago
My one gripe with this article is that it doesn't really explain why a wrapper over native toolkits is untenable. There haven't been many attempts of this idea, of which wxWidgets and libui are a couple. Yes, it exposes its own complexity, but I would rather start with a GUI that's portable/accessible, and then worry about its look-and-feel.
- ReactiveJelly 3y ago
  It really bugs me that native toolkits, and even cross-platform kits like GTK+ or Qt, seem to reject testability. They want you to open a window and build a widget inside the window. The APIs for rendering to a byte buffer and injecting bogus input events seem kinda weak. If I make my own toolkit, I'll focus on that first. I don't want such a huge part of the app to be an untestable I/O leaf.
  - throwaway2037 3y ago
    In the case of Qt, this is simply untrue. Google "qt gui unit tests" and you will find plenty of content -- from Qt and blog posts with Real World cookbooks and stories. And, Win32 has a whole separate subsystem for unit testing UIs. Read more here: Win32 -> "UI Automation Test Library" Man, there is so much damn misinformation about Qt on HN. It is tiring. I don't understand the source of this misinformation. Part of it probably stems from their various licensing mishaps over the years that seeded a bunch of FUD. It's a ridiculously good cross-platform UI library. KDE would not exist without it! I don't work for them, but I have used the toolkit for years. Nothing beats it. Yes, it is huge, but it does everything you could ever need.
    - ReactiveJelly 3y ago
      I used Qt4 for a few years and never found an easy way to run a widget outside the context of a window. Maybe I didn't check the docs closely, maybe it's better in Qt6. I stopped working on GUIs a while back. Fwiw HTML and xaml were just as bad for that.
gjvc 3y ago
http://www.jidesoft.com/ http://www.jidesoft.com/
- phil-martin 3y ago
  Oh wow, I haven't thought about Jidesoft in YEARS. I used it back in the early 2000 to add some much nicer data grids, toolbars and other things to our mining software package. Those were the days!
  - gjvc 3y ago
    place i was at used it for an options trading platform in 2006
wahern 3y ago
For a recent project (http://keymux.com/ http://keymux.com/) I chose Yue (https://libyue.com/ https://libyue.com/), a cross-platform native widget GUI toolkit for C++, JavaScript/Node.js, and Lua. I've only used the Lua interface and macOS backend, but it has worked quite well, despite the very steep learning curve. This was also my first desktop GUI app, so I had to learn many implicit concepts that weren't obvious from the otherwise extensive documentation. Yue was the only option that 1) supported macOS, 2) supported Lua, 3) was sufficiently comprehensive to build a non-toy GUI app, 4) and that I could integrate into my (static) build. I couldn't even get the wxWidgets Lua interfaces to compile, and Qt and FLTK wrappers had similar stories, whereas reverse-engineering the baroque Yue build (based on Google's internal build systems) was relatively simple. The first candidate I tried was libui, but it had some crashing bugs that didn't inspire confidence, the widget set was bare, and most importantly development had ceased. Yue had some sharp edges, but I was able to work around them whilst patiently waiting for patches and fixes upstream. Immediate mode interfaces were a non-starter for me. For a non-trivial set of otherwise typical controls and window management you have to implement too much yourself, plus being non-native they not only felt wrong (which admittedly is somewhat subjective; the younger crowd seems to think non-native, immediate mode interfaces look more state-of-the-art), but lacked other interfaces for proper desktop integration, like theme change signaling (i.e. notification that a user switch between light and dark modes in the macOS system settings panel). All in all I would highly recommend Yue.
- vram22 3y ago
  >All in all I would highly recommend Yue >despite the very steep learning curve. ? I used your quotes out of context, I know, because those phrases are in different parts of your comment, and I did it because I could, ahem, reuse your words, and it looked cool to do so, but the question is genuine: Why do you recommend it despite the very steep learning curve? Because of support for Lua? macOS?
  - wahern 3y ago
    I meant that the steep learning curve related to the intrinsic complexity of dealing with desktop GUI frameworks, which I lacked experience with previously: terminology, layout and flow caveats (e.g. with embedded scroll panels, limitations on autosizing and reflow in the absence of explicit dimensions), etc. The Yue author clearly has extensive GUI SDK experience, and while comprehensive, like many open source projects the Yue documentation assumes some minimal understanding of the concepts and inevitable limitations. The only possibly unnecessary complexity with Yue is the build framework, but that sort of thing can be quite subjective and a function of various requirements (personal, third-party libraries--it uses Facebook's Yoga for automagic layout and reflow) and familiarity. Excepting libui (which is basically defunct), all the frameworks I investigated had terribly complex builds, so it's pretty much par for the course. Notably, Yue releases prebuilt binaries with every release. I couldn't make use of those because I wanted a fully static, fat application binary (x86-64 + arm64), and also I needed a convenient, local Yue build for writing and testing patches.
whartung 3y ago
Long ago, as the silicon on the planet was still cooling, a friend of mine did exactly this. And single handedly. What he essentially did was he cracked open “Inside Mac” and ported it to a C library that ran on the PC. He did the bulk of it too. Memory manager, Resource manager, QuickDraw, Window manager, Event manager, Font manager. They changed it up, they didn’t copy the window gadgets and such, scrollbars worked (and looked) different. But the task was to port a native Macintosh application to the PC, pre-Windows, and keep it portable. It was not a one way trip. The company maintained both versions. Got the bulk of it done in less than a year. Obviously this was early Macintosh. B&W, bitmap fonts (though the application generated PostScript for printing). Yup, they don’t call them The Old Days for nothing.
- winrid 3y ago
  What was the application? So interesting.
- OnlyMortal 3y ago
  Heh. I did a partial port of Resource Manager so I could load up Macintosh Fonts on an Amiga. Aspect ratio was fun as the Mac had square pixels.
- DeathArrow 3y ago
  Everything that was simple 20 years ago is now 100x more complicated. Part of the reasons made programming interesting for me long time ago was that fact that one person could tackle a rather complex job all by himself. You could write a GUI, a game, a text processor, a compiler and even an OS as a one person team.
  - elevation 3y ago
    You could still do all these things before the summer is out. Compiler design is no harder today than 20 years ago. Any text processor you would have created single-handedly 20 years ago is similarly doable. Simple, performant GUIs are easy if you restrict yourself to a single platform. Windows 11 still runs win32 apps, Ubuntu/GTK is also straightforward. For an OS, consider targeting a well-documented microcontroller. Some variants are approaching a similar amount of compute and RAM as 25-year-old PC hardware but have Ethernet ports and/or LCD displays. And if you just want to build a game to say you did, you could build just about anything in the browser using vector graphics primitives reminiscent of DOS.
iFire 3y ago
Working on Godot Engine, in a team adjacent to things like Unicode fonts (with left to right languages etc.) and multiple windows support was watching an uphill struggle for Godot Engine 4.0. I have no idea how other team succeed at it either. <edit> Recognize every item on this list. EVEN THE WEBVIEW ONE https://github.com/godotengine/godot-proposals/issues/960 https://github.com/godotengine/godot-proposals/issues/960 Unicode variables names https://github.com/godotengine/godot-proposals/issues/916 https://github.com/godotengine/godot-proposals/issues/916
c-smile 3y ago
These bullet points are exactly what I did in Sciter (https://sciter.com https://sciter.com) - Windowing -- Tabs -- Menus -- Painting -- Animation -- Text -The compositor -Handling input -- Pointer input -- Keyboard input - Accessibility - Internationalization and localization - Cross-platform APIs - The web view - Native look and feel On top of that DOM and CSS implementations to achieve declarative UI. And JS as a languuage behind UI - declarative in some sense way of defining UI behavior.
- winrid 3y ago
  What about the ability to have platform specific code? Like serial/USB communication. Right now I'm using libgdx so I can have a cross platform UI and then specific code for USB communication for each platform. Sciter would be great if I could use it.
  - c-smile 3y ago
    You can extend Sciter by native components. As purely functional (native classes and methods in JS) as visual (custom UI components).
    - winrid 3y ago
      Okay, so I can get access to platform specific APIs? When you say "Native compontents" it still sounds very UI focused :P
tayistay 3y ago
> Since GPUs are good at drawing 3D scenes, and since 3D scenes seem “more complicated” than 2D scenes, it may feel like a natural conclusion that GPUs should handle 2D trivially. They do not. While not trivial, nanovg shows that it can be done reasonably well. At least well enough for a GUI. Thankfully a GUI doesn't need a very advanced 2D rendering engine (see Dear Imgui or egui). Vector art apps can write their own engines.
hsn915 3y ago
If you're interested in what it takes to render bidirectional text with complex scripts and line breaking, I had the experience of implementing that (in immediate mode too) and wrote about it here: https://hasen.substack.com/p/imgui-text https://hasen.substack.com/p/imgui-text
- ramshanker 3y ago
  Thankyou. I am starting an experimental desktop application myself and currently at library selection phase. This is going to help few decisions.
koonsolo 3y ago
Unfortunately I know all too well. And it's only a small part of my project (rpgplayground.com). I wanted to have a GUI inside the game itself (so you can edit games while you play), but that means I had to develop my own GUI. I created simple game GUI's before, so I thought this wasn't a big of a deal. Oh boy was I wrong. A couple of buttons and textfields is very different from a full widget toolkit. And then another thing: I originally developed RPG Playground in ActionScript3, so I latched on to the native textfield they provide. In fact, most GUI toolkits you see are able to make use of some native textfield functionality. So after Flash was killed, I ported my product to Haxe. And then realized that I can't really latch on to any native textfield functionality. Yeah, you guessed it, I had to write my own textfield code: word wrapping, mouse handling, ... . That was another project in itself.
needle0 3y ago
Only one paragraph for l10n and i18n? A GUI framework written only by people speaking English is 99% most definitely going to get font display wrong ( https://heistak.github.io/your-code-displays-japanese-wrong/ https://heistak.github.io/your-code-displays-japanese-wrong/ ) and will have a plethora of locale-specific behavior bugs ( https://heistak.github.io/your-code-displays-japanese-wrong/otherthings.html https://heistak.github.io/your-code-displays-japanese-wrong/... ).
laeri 3y ago
I am not sure why this strange fixation on tabs as an important ui element exists. In most cases such as within a browser tabs are horrible to navigate. In my opinion they only make sense if you have a fixed number of diffferent "submenus" that you want to show. The tabs will always be named the same (for the different categories) and they will stay at the same place. Using dynamic content for tab is just only barely useful and still persists in many browser and applications (such as postgres or obisidan). What happens is that you will open a large number of things in this will completely clutter your tabview. A list which is filterable will always be better to navigate than some tabs with dynamic content.
deleted 3y ago
[deleted]
criddell 3y ago
My wish: framework developers give up on cross-platform. Write a framework tightly integrated with macOS or Windows or whatever OS you love. Once you do that, many of the concerns the author described become much easier to tackle. The article specifically mentions Rust which does have Mac and Windows bindings. That’s necessary, but not sufficient. Where is the macOS or Windows Rust framework that makes writing fast, safe, beautiful apps in Rust the best and easiest choice? Surely a developer with modern tools and knowledge can do better than Microsoft did in 1992 with C++ and MFC.
soulbadguy 3y ago
I think the flutter (and to some extend QT) path is the future of x-platform GUI framework. Lift the complete GUI framework and rendering outside of the OS and implemement everything in the app as a library. A lot of the complexity mentioned is just the result of the inability of the big platform (android,ios,windows) to agree on a coherent set of api. The core reason the web worked so well as a target is that it's a well defined single uniformed API any body can target. The obvious downside is the lost of "native feel". But i think this has been overblown. Probably a reaction to horrible look for 2000/2010 java/jwt applications. But the web doesn't have a native feel, but still can look great everywhere.

195 points by eatonphil 3y ago

As I'm looking through the Skia APIs I have the dumb question: why doesn't Skia have its own wrappers for input method editors (at least on Windows and macOS)? Or maybe it does and I'm missing it. Implementing these APIs for Windows and macOS seem super arcane. It's hard to find docs on implementing them. I guess there must be a good reason there are not cross-platform libraries that abstract IME specifically.

adamnemecek 3y ago
Presumably to keep the focus of the library small.
- eatonphil 3y ago
  I wasn't under the impression Skia had a focus on being particularly small. (Though I have no clue. I'm just getting into this stuff.)
  - adamnemecek 3y ago
    Check out nanovg and all the alternatives.
sporedro 3y ago
I can’t answer from rust perspective, but just my opinion. GUI frameworks in general seem like an atrocity, you have QT and that seems like it besides proper native development and targeting 1 platform. Java still seems like the only language with cross platform GUI and swing/awt are on the way out with javaFX being “abandoned”? (Probably not the right term but it never was made main stream). You got to Python, etc and it’s an absolute mess. C/c++ have a few but cross platform still seems tough. Don’t even get me started on the mess of electron.
- chairhairair 3y ago
  You haven’t heard of Flutter?
  - brabel 3y ago
    Exactly... looks like most people don't know that Flutter uses Skia... and it's a real multi-platform framework (Windows, MacOS, Linux, Android, iOS, even Web), whether you like it or not.
- giraffe_lady 3y ago
  What's interesting to me is that there are a handful of languages that include gui frameworks: tcl with tk, erlang binds wxwidgets, and racket has its own thing built on gtk. It's curious what these languages have in common too: as languages almost nothing. But they're all venerable, proven & respected in their domains if not beloved, and relatively unpopular. I don't know how to interpret that. Maybe it's just a coincidence. Or stdlib gui frameworks are just out of style and it's survivorship from the old ones. But then python is from around the same time, why doesn't it?
  - remexre 3y ago
    tkinter is the Python one!
    - vram22 3y ago
      Ruby has a Tk-based one too, but I don't remember the name, since I used it only a little, years ago, though I did some non-GUI Ruby and Rails web work.
      - beeburrt 3y ago
        RubyMotion? http://www.rubymotion.com/ http://www.rubymotion.com/
        3y ago
ReactiveJelly 3y ago
Skia only does rendering, not input, right?
c-smile 3y ago
IME handling must be implemented at OS level. IME is not Skia's responsibility.
- throwaway2037 3y ago
  IME handling must be implemented at OS level. Really? X11 has a wide variety of IMEs. That's user space, not "OS level" (kernel?). A different view: It might be possible to write an IME for X11 using Skia. :)
  - okanat 3y ago
    OS level includes the core system libraries in the userspace. Of course you can argue no such thing exist in Linux. It is the odd one among all OSes, both major and minor, in not providing any stable and well-defined system layer. The lack of unified standards in X11 and especially in Wayland/libinput is a huge source of problems in accessiblity and user experience of traditional Linux environments. Each of those IMEs (ibus, fctx,...) are a major pain to setup and configure correctly. They often don't look "native" to the toolkit of the desktop.
TazeTSchnitzel 3y ago
SDL2, which is an abstraction intended for games (gives you a window, sets up OpenGL and handles input events, but leaves the drawing to you), has a very simple text input API that can handle IMEs: https://wiki.libsdl.org/SDL2/SDL_StartTextInput https://wiki.libsdl.org/SDL2/SDL_StartTextInput + https://wiki.libsdl.org/SDL2/SDL_SetTextInputRect https://wiki.libsdl.org/SDL2/SDL_SetTextInputRect. But the trade-off is that you can't write a text editor with this. It just lets the user type text using the OS's text field or similar and the app is not in control while they do so.

Solvency 3y ago

I think the 3 absolute demons that will eventually seek to destroy you in any homebrewn GUI framework will eventually be: - Rendering and dealing with text in all of its extreme permutation. Styling. Localization. Character sets. Etc. - Modern accessibility standards. There are countless annoying yet de facto UX patterns that are just nightmarish to check off the list from scratch. Inputs/forms/etc. Even worse than accessibility, because you can decide to forgo that completely if you really wanted. The sheer volume of UX use cases and edge cases involved in even seemingly basic input components is also an exercise in rote dread. You've got input validation, error states, just so many ergonomics to deal with. - Fluid layouts and scaffolding. This is where modern HTML/CSS finally starts to shine because making flexible layouts is actually quite painless. But it's a motherfucker to roll your own approach.

moron4hire 3y ago
But you can't forgo accessibility. Anyone who would make software with your framework would be in violation of several laws. EDIT: I see that there are people down voting several comments in this thread in support of accessibility. I wonder what disagreement that you have? Surely it can't be "not a large enough market". There are more legally blind people in the world than Firefox users, yet web developers will happily test compatibility with that dying browser and eschew screen reader testing.
- TheBrokenRail 3y ago
  Not a lawyer, but if this was true, wouldn't a bunch of developers and companies be facing fines? Especially smaller open-source stuff. And larger companies as well (for instance, Reddit's mobile app is infamously inaccessible).
  - moron4hire 3y ago
    Yes, they would. We're all only getting away with it because nobody has complained. It's a massive risk that companies are running. I don't know how Reddit has skirted it for so long, but there have been several high profile cases in recent years.

groby_b 3y ago

This is all a very neat summary, but I'll go out on a limb and say that for most of us, the first-order approximation should be "don't. Just don't". Been there. Done/sort of doing that. Have impressive collection of scars. There are no t-shirts to be had. This document only barely scratches the surface of the work necessary. If this is your calling, by all means, but expect to sink a good chunk of your life into it. Things are glossed over in a paragraph that mean years of work. (My favorite is the internationalization section, closing with "But don’t worry: there’s a standard. All you need to do is implement it." - All you need to do, indeed :) To be clear: Colin knows it's years of work. He's been working on a number of excellent projects in the space (xi-editor, druid, ...). But I really feel this deserves a warning sticker, lest you accidentally spend a decade or two of your life on it.

ReactiveJelly 3y ago
Eh, re-inventing wheels is fun. I learned a lot making my own games from scratch with no engine. I'll make a bad one-user GUI kit some day too.
c-smile 3y ago
Well, it is definitely not a suicide mission. At least in my Sciter I've implemented all those by myself in reasonable time frame - first version was made in 9 months. But "yes", you need some prior experience, in order to come up with flexible architecture that will allow to expand it further without major redesigns. First version had DOM/CSS and used just GDI. GPU support (Direct2D, OpenGL|Metal|Vulkan via Skia) was added later with API staying the same.

dang 3y ago

Discussed at the time: So you want to write a GUI framework - https://news.ycombinator.com/item?id=28127492 https://news.ycombinator.com/item?id=28127492 - Aug 2021 (173 comments)

smasher164 3y ago

My one gripe with this article is that it doesn't really explain why a wrapper over native toolkits is untenable. There haven't been many attempts of this idea, of which wxWidgets and libui are a couple. Yes, it exposes its own complexity, but I would rather start with a GUI that's portable/accessible, and then worry about its look-and-feel.

ReactiveJelly 3y ago
It really bugs me that native toolkits, and even cross-platform kits like GTK+ or Qt, seem to reject testability. They want you to open a window and build a widget inside the window. The APIs for rendering to a byte buffer and injecting bogus input events seem kinda weak. If I make my own toolkit, I'll focus on that first. I don't want such a huge part of the app to be an untestable I/O leaf.
- throwaway2037 3y ago
  In the case of Qt, this is simply untrue. Google "qt gui unit tests" and you will find plenty of content -- from Qt and blog posts with Real World cookbooks and stories. And, Win32 has a whole separate subsystem for unit testing UIs. Read more here: Win32 -> "UI Automation Test Library" Man, there is so much damn misinformation about Qt on HN. It is tiring. I don't understand the source of this misinformation. Part of it probably stems from their various licensing mishaps over the years that seeded a bunch of FUD. It's a ridiculously good cross-platform UI library. KDE would not exist without it! I don't work for them, but I have used the toolkit for years. Nothing beats it. Yes, it is huge, but it does everything you could ever need.
  - ReactiveJelly 3y ago
    I used Qt4 for a few years and never found an easy way to run a widget outside the context of a window. Maybe I didn't check the docs closely, maybe it's better in Qt6. I stopped working on GUIs a while back. Fwiw HTML and xaml were just as bad for that.

gjvc 3y ago

http://www.jidesoft.com/ http://www.jidesoft.com/

phil-martin 3y ago
Oh wow, I haven't thought about Jidesoft in YEARS. I used it back in the early 2000 to add some much nicer data grids, toolbars and other things to our mining software package. Those were the days!
- gjvc 3y ago
  place i was at used it for an options trading platform in 2006

wahern 3y ago

For a recent project (http://keymux.com/ http://keymux.com/) I chose Yue (https://libyue.com/ https://libyue.com/), a cross-platform native widget GUI toolkit for C++, JavaScript/Node.js, and Lua. I've only used the Lua interface and macOS backend, but it has worked quite well, despite the very steep learning curve. This was also my first desktop GUI app, so I had to learn many implicit concepts that weren't obvious from the otherwise extensive documentation. Yue was the only option that 1) supported macOS, 2) supported Lua, 3) was sufficiently comprehensive to build a non-toy GUI app, 4) and that I could integrate into my (static) build. I couldn't even get the wxWidgets Lua interfaces to compile, and Qt and FLTK wrappers had similar stories, whereas reverse-engineering the baroque Yue build (based on Google's internal build systems) was relatively simple. The first candidate I tried was libui, but it had some crashing bugs that didn't inspire confidence, the widget set was bare, and most importantly development had ceased. Yue had some sharp edges, but I was able to work around them whilst patiently waiting for patches and fixes upstream. Immediate mode interfaces were a non-starter for me. For a non-trivial set of otherwise typical controls and window management you have to implement too much yourself, plus being non-native they not only felt wrong (which admittedly is somewhat subjective; the younger crowd seems to think non-native, immediate mode interfaces look more state-of-the-art), but lacked other interfaces for proper desktop integration, like theme change signaling (i.e. notification that a user switch between light and dark modes in the macOS system settings panel). All in all I would highly recommend Yue.

vram22 3y ago
>All in all I would highly recommend Yue >despite the very steep learning curve. ? I used your quotes out of context, I know, because those phrases are in different parts of your comment, and I did it because I could, ahem, reuse your words, and it looked cool to do so, but the question is genuine: Why do you recommend it despite the very steep learning curve? Because of support for Lua? macOS?
- wahern 3y ago
  I meant that the steep learning curve related to the intrinsic complexity of dealing with desktop GUI frameworks, which I lacked experience with previously: terminology, layout and flow caveats (e.g. with embedded scroll panels, limitations on autosizing and reflow in the absence of explicit dimensions), etc. The Yue author clearly has extensive GUI SDK experience, and while comprehensive, like many open source projects the Yue documentation assumes some minimal understanding of the concepts and inevitable limitations. The only possibly unnecessary complexity with Yue is the build framework, but that sort of thing can be quite subjective and a function of various requirements (personal, third-party libraries--it uses Facebook's Yoga for automagic layout and reflow) and familiarity. Excepting libui (which is basically defunct), all the frameworks I investigated had terribly complex builds, so it's pretty much par for the course. Notably, Yue releases prebuilt binaries with every release. I couldn't make use of those because I wanted a fully static, fat application binary (x86-64 + arm64), and also I needed a convenient, local Yue build for writing and testing patches.

whartung 3y ago

Long ago, as the silicon on the planet was still cooling, a friend of mine did exactly this. And single handedly. What he essentially did was he cracked open “Inside Mac” and ported it to a C library that ran on the PC. He did the bulk of it too. Memory manager, Resource manager, QuickDraw, Window manager, Event manager, Font manager. They changed it up, they didn’t copy the window gadgets and such, scrollbars worked (and looked) different. But the task was to port a native Macintosh application to the PC, pre-Windows, and keep it portable. It was not a one way trip. The company maintained both versions. Got the bulk of it done in less than a year. Obviously this was early Macintosh. B&W, bitmap fonts (though the application generated PostScript for printing). Yup, they don’t call them The Old Days for nothing.

winrid 3y ago
What was the application? So interesting.
OnlyMortal 3y ago
Heh. I did a partial port of Resource Manager so I could load up Macintosh Fonts on an Amiga. Aspect ratio was fun as the Mac had square pixels.
DeathArrow 3y ago
Everything that was simple 20 years ago is now 100x more complicated. Part of the reasons made programming interesting for me long time ago was that fact that one person could tackle a rather complex job all by himself. You could write a GUI, a game, a text processor, a compiler and even an OS as a one person team.
- elevation 3y ago
  You could still do all these things before the summer is out. Compiler design is no harder today than 20 years ago. Any text processor you would have created single-handedly 20 years ago is similarly doable. Simple, performant GUIs are easy if you restrict yourself to a single platform. Windows 11 still runs win32 apps, Ubuntu/GTK is also straightforward. For an OS, consider targeting a well-documented microcontroller. Some variants are approaching a similar amount of compute and RAM as 25-year-old PC hardware but have Ethernet ports and/or LCD displays. And if you just want to build a game to say you did, you could build just about anything in the browser using vector graphics primitives reminiscent of DOS.

iFire 3y ago

Working on Godot Engine, in a team adjacent to things like Unicode fonts (with left to right languages etc.) and multiple windows support was watching an uphill struggle for Godot Engine 4.0. I have no idea how other team succeed at it either. <edit> Recognize every item on this list. EVEN THE WEBVIEW ONE https://github.com/godotengine/godot-proposals/issues/960 https://github.com/godotengine/godot-proposals/issues/960 Unicode variables names https://github.com/godotengine/godot-proposals/issues/916 https://github.com/godotengine/godot-proposals/issues/916

c-smile 3y ago

These bullet points are exactly what I did in Sciter (https://sciter.com https://sciter.com) - Windowing -- Tabs -- Menus -- Painting -- Animation -- Text -The compositor -Handling input -- Pointer input -- Keyboard input - Accessibility - Internationalization and localization - Cross-platform APIs - The web view - Native look and feel On top of that DOM and CSS implementations to achieve declarative UI. And JS as a languuage behind UI - declarative in some sense way of defining UI behavior.

winrid 3y ago
What about the ability to have platform specific code? Like serial/USB communication. Right now I'm using libgdx so I can have a cross platform UI and then specific code for USB communication for each platform. Sciter would be great if I could use it.
- c-smile 3y ago
  You can extend Sciter by native components. As purely functional (native classes and methods in JS) as visual (custom UI components).
  - winrid 3y ago
    Okay, so I can get access to platform specific APIs? When you say "Native compontents" it still sounds very UI focused :P

tayistay 3y ago

> Since GPUs are good at drawing 3D scenes, and since 3D scenes seem “more complicated” than 2D scenes, it may feel like a natural conclusion that GPUs should handle 2D trivially. They do not. While not trivial, nanovg shows that it can be done reasonably well. At least well enough for a GUI. Thankfully a GUI doesn't need a very advanced 2D rendering engine (see Dear Imgui or egui). Vector art apps can write their own engines.

hsn915 3y ago

If you're interested in what it takes to render bidirectional text with complex scripts and line breaking, I had the experience of implementing that (in immediate mode too) and wrote about it here: https://hasen.substack.com/p/imgui-text https://hasen.substack.com/p/imgui-text

ramshanker 3y ago
Thankyou. I am starting an experimental desktop application myself and currently at library selection phase. This is going to help few decisions.

koonsolo 3y ago

Unfortunately I know all too well. And it's only a small part of my project (rpgplayground.com). I wanted to have a GUI inside the game itself (so you can edit games while you play), but that means I had to develop my own GUI. I created simple game GUI's before, so I thought this wasn't a big of a deal. Oh boy was I wrong. A couple of buttons and textfields is very different from a full widget toolkit. And then another thing: I originally developed RPG Playground in ActionScript3, so I latched on to the native textfield they provide. In fact, most GUI toolkits you see are able to make use of some native textfield functionality. So after Flash was killed, I ported my product to Haxe. And then realized that I can't really latch on to any native textfield functionality. Yeah, you guessed it, I had to write my own textfield code: word wrapping, mouse handling, ... . That was another project in itself.

needle0 3y ago

Only one paragraph for l10n and i18n? A GUI framework written only by people speaking English is 99% most definitely going to get font display wrong ( https://heistak.github.io/your-code-displays-japanese-wrong/ https://heistak.github.io/your-code-displays-japanese-wrong/ ) and will have a plethora of locale-specific behavior bugs ( https://heistak.github.io/your-code-displays-japanese-wrong/otherthings.html https://heistak.github.io/your-code-displays-japanese-wrong/... ).

laeri 3y ago

I am not sure why this strange fixation on tabs as an important ui element exists. In most cases such as within a browser tabs are horrible to navigate. In my opinion they only make sense if you have a fixed number of diffferent "submenus" that you want to show. The tabs will always be named the same (for the different categories) and they will stay at the same place. Using dynamic content for tab is just only barely useful and still persists in many browser and applications (such as postgres or obisidan). What happens is that you will open a large number of things in this will completely clutter your tabview. A list which is filterable will always be better to navigate than some tabs with dynamic content.

deleted 3y ago

[deleted]

criddell 3y ago

My wish: framework developers give up on cross-platform. Write a framework tightly integrated with macOS or Windows or whatever OS you love. Once you do that, many of the concerns the author described become much easier to tackle. The article specifically mentions Rust which does have Mac and Windows bindings. That’s necessary, but not sufficient. Where is the macOS or Windows Rust framework that makes writing fast, safe, beautiful apps in Rust the best and easiest choice? Surely a developer with modern tools and knowledge can do better than Microsoft did in 1992 with C++ and MFC.

soulbadguy 3y ago

I think the flutter (and to some extend QT) path is the future of x-platform GUI framework. Lift the complete GUI framework and rendering outside of the OS and implemement everything in the app as a library. A lot of the complexity mentioned is just the result of the inability of the big platform (android,ios,windows) to agree on a coherent set of api. The core reason the web worked so well as a target is that it's a well defined single uniformed API any body can target. The obvious downside is the lost of "native feel". But i think this has been overblown. Probably a reaction to horrible look for 2000/2010 java/jwt applications. But the web doesn't have a native feel, but still can look great everywhere.