Comment by gwmnxnp_516a | Hacker News Reader

Comment by gwmnxnp_516a | Hacker News Reader

The problem of creating GUIs libraries almost from scratch is the platform fragmentation, which means that a cross-platform GUI libraries would have to abstract away the Windows API win32, that is one of the most stable and most complete GUI libraries; MacOSX Objective-C Cocoa; Unix and Linux X11 - X Windows System, that lacks Win32 button and other higher level widgets, in this case it is better to use GTK as backend instead of targeting X11 directly that may even be replaced with Wayland on major Linux distribtions; Linux Wayland backend directly; Linux framebuffer for embedded Linux systems; or OpenGL for a immediate mode GUI like Imgui. Another trouble is that GTK is not so stable like Win32 and has many breaking changes on every release that may require anything depending on this library to be modified.

The following design patterns are widely used with graphical user interfaces: observer-design pattern; model-view-controller; model-view-presentation; two-way-data binding; property binding; command design pattern; and composite design patterns for representing a collection of objects as single object.

For understanding event loop it may be much easier to implement a Xterm or VT100 keyboard-driven terminal user interface TUI since this does not requiring dealing with too many backends.

Forget cross-platform. There are no great cross-platform toolkits.

Pick a platform and make the best application you can on that platform.

Do you see a future where cross-platform could essentially be a set of tools/frameworks to build high performance native experiences targeting the browser as the primary runtime?

Eventually - Google is pushing this with Flutter and Microsoft is pushing this with Blazor.

> There are no great cross-platform toolkits.

True. But there are several entirely adequate cross-platform toolkits. Pick a toolkit, not a platform.

(GTK+ (via gtkmm) user for 23 years, on 3+ platforms)

The greatest cross-platform toolkit is Qt that abstracts away all platforms including mobile and embedded systems. Qt also works on top framebuffer on embedded Linux and on other RTOS operating systems. The disadvantage of Qt is that is a C++ library with a lack of C ABI or C api (extern "C") that would allow Qt to be called from other programming languages than C++. That is the reason why Gtk has far more bindings than Qt, although they are unstable due to Gnone breaking changes and lack of backward compatibility.

Most applications just pick Windows win32 API or MacOSX and forgets about everything else and are never released for Linux or other Unices, unless the application uses electron, Qt with C++, Qt with Python or Java SWING like JetBrains IDEA IDE family. The main problem of Linux desktop is the lack of a high level graphics library toolkit with a stable API, ABI and a C interface that does not introduce breaking changes on every release. Unlike Gtk, Qt is more stable, but it lacks a C API and C++ has a fragile ABI not friendly to foreign-function interface or cross-language linking.

> in this case it is better to use GTK as backend instead of targeting X11 directly that may even be replaced with Wayland on major Linux distribtions;

X11 can work on Windows (many Xservers available, since forever), MacOS (used to ship with one, but now you've got to install one), and you can run an Xwayland in Wayland. So it's as cross platform as you can get. Might not look great, but then cross platform doesn't usually look great anyway.

If you're going to do X, avoid Xlib, it adds restrictive abstractions on top of X protocol and really confuses things. XCB is much closer to just reasonable interfaces to the protocol. Ultimately, X11 is a distributed systems communication protocol which happens to have graphical output as a side effect; understanding the communications part first lets you get the most out of it.

Reply on news.ycombinator.com