Solving the GUI Problem
Writing graphical user interfaces that work across multiple platforms is notoriously hard or complex. What can we do?
Lots of ways exist today for writing cross platform GUI software. You could use web technologies, Qt, Godot and many other technologies.
Yet none of the solution are all that great. I have used Qt for many years which is quite well made for C++ GUI development. Yet it is a large installation and creating bindings for other languages is less than ideal thanks to it being made in C++ which has no stable well defined binary interface.
Nor does it ever really look good on all platforms. E.g. Qt will use native drawing function to draw things like buttons and drop down lists. However these are not spaced and layed out in a manner that is common on e.g. the Mac platform making it all look weird, wrong and out of place.
An alternative is to use Web technologies. Either use browser or something like Electron. This has certainly been a huge success. But there is a huge downsides. Web technology has become extremely bloated. Web browsers are famously one of the most resource intensive applications on your computer gobbling up memory and battery life like nothing else.
A Third Way, Learning from POSIX
Linux, macOS and other Unix based operating systems, including non-Unix ones like BeOS all support the POSIX APIs. This API deals with things like reading and writing to files and to console. With POSIX you have a common standard which makes it possible to fairly easily make text based command line tools which can easily be ported across multiple platforms.
Yet POSIX does in no way try to encompass everything an OS does. It is simply a subset.
As someone passionate about user interface design, I belive it is wrong to take the approach of trying to make complete cross platform GUI toolkits. It will almost always mean selecting the smallest common denominator. If every application is made to work cross platform, then what exactly is the point of having multiple platforms?
If all software you can buy works exactly the same on Linux, macOS and Windows, then why bother with different platforms at all?
I use macOS because I like how Mac software works. The philosophy of how things are laid out, how the interactions with the user is setup, choice of colors and fonts. How one piece of software interacts with another. A world where all my software works like Windows software would be a world I would very much be against.
Yet not all software has the most sophisticated demand. Some software just needs to work everywhere without effort. E.g. everyone should be able to access their bank account, pay their taxes, setup a doctors appointment regardless of operating system they use. The solution for such needs has today often been the Web. That is fine. The web serves as a least common denominator, which does not serve up application in a unique fashion for each platform.
Somehow we need to satisfy both of these needs:
- Make it easy to make cross platform software to serve core user needs.
- Allow each platform to express their unique features and abilities.
My proposal to solve this would be to define an industry standard akin to POSIX for graphical user interfaces. Like POSIX it would be limited. It would not be for making any kind of software. It would not be to have the more creative and advance widgets. Rather it would contain enough variety that all key software could be delivered. You should be able to use it to make an editor, email reader, messaging app, banking application, tax payment app etc. You get the idea.
It is not necessarily something you would use to make a 3D modeling tool, high performance first person shooter, web browser or advance desktop publishing application or video editor.
A Standard Followed By Every OS
The idea would be for this to be a standard that every OS implements. Each vendor agrees to implement this minimal standard. By keeping it minimal there is also a chance that each vendor will actually comply and fully implement it.
What are the advantages of this approach over the alternatives? The alternatives tend to wrap existing GUI toolkits in new layers. This creates new problems as there is not always a clean mapping to some common subset. Also these wrappings tend to approach the problem as an attempt to fully wrap and reproduce the full richness of GUI experience on one platform onto another.
We end up in a world, with layers, upon layers upon layers. Software development ends up being excessively bloated. For instance Qt wraps native toolkits but because Qt is C++, everyone using a different language has to wrap Qt in another layer. This creates deep complex layers where problems can be hard to diagnose.
The Web creates its own unique set of problems. It is a platform meant for news papers, video services like Netflix, books, information content, applications. It is trying to serve every possible need creating an extremely complex system which is also extremely resource intensive. It was never intended as an application platform. There are no good web concepts for local applications exchanging data with each other e.g. Understanding things like drag and drop, a local file system etc.
Thus we need something simpler designed for applications that lives locally.
Learning from the Web
Yet the Web has numerous valuable lessons to teach us. It reminds us of an old lesson taught to us by Unix: The value of plain text based interfaces and protocols.
Any programming language in principle work with plain text. Thus a large variety of language has been used over the years to host web pages.
Thus a cross platform GUI standard should not be defined as some sort of binary interface designed for a particular language like C/C++ or Java.
Instead it should be a text based protocol. This could work as either communication through sockets, or by reading or writing particular files in the filesystem. Alternatively some new communication channel must be standardized across all platforms for this particular purpose. The point is that you have a few simple access point which could be easily implemented in any programming language.
From that point on, creating and interacting with a GUI would mean simply interacting with a well defined plain text protocol that works on all platforms.
There are many good ideas in HTML and XML, but these are standards well suited for documents and less so for interactive applications. Hence I don’t think a text protocol should be built on them. Something more similar to JSON would make more sense. Although we probably want something in between HTML and JSON. Richer in what can be expressed than JSON but not as rich as the HTML/CSS combo.
The point isn’t to support the creation of every possible type of application. Instead it is to allow for say 80% of applications.
And I don’t view that as a deficiency. There must be a chance for each platform to offer unique experiences tailored for their platform. Trying to cover every possible need will simply result in an overly complex standard, that is never fully supported on every OS. Thus we end up with Windows and Mac specific App versions, because features only properly supported on one platform is used.
Instead we want a minimal useful set of features with an enduring quality, that can stay unchanged for long periods of time.
Benefits
Whatever programming language you use, all you will not to be able to do is to open a file or socket connection and manipulate plain UTF8 text to create a UI and respond to events. Because this will be supported in every OS, there will be no special packages or libraries to install.
People will be able to write even simple shell scripts which can show a GUI.
People who create new programming languages are able to instantly offer their developers a way to create GUIs for any platform that runs natively.
Generic tools can be made to support development. All they need to grasp is how to manipulate plain text. You could have tools that monitor communications with the GUI server to debug GUI problems much as you can do with Web development today.
Unlike the Web there will be no need to have huge web browsers installed consuming a ton of memory and battery. Applications don’t have to live inside the context of a web browser. Thus native OS functionality for switching between applications, watching resource usage or shutting them down will work. Likewise you can associate files with particular applications to be opened. All sorts of stuff not easily supported by a web app.
Because this should be built as an OS standard rather than encapsulated into an a single application, there can be OS wide services for picking any window of any application and look at e.g. the communication going on with that window. Tools could be built into the OS to support things like automated testing of the GUI, by recording textual communication between application and window.
Improving on the Web Metaphor
The web has no good system for defining new components. In say a C++ program you can define a new GUI widget through subclassing and easily reuse it. HTML does not offer a way of defining new HTML tags, but sub typing existing ones.
An application oriented text protocol for GUIs should facilitate these kinds of things. It needs to make it easy to subtype existing GUI components, and have ways of making callbacks easy to do. E.g. we could imagine reading from particular files or sockets for messages from GUI components, such as being clicked, item selected etc.
Extensions
Borrowing from RISC-V ideas, it might be useful to define the system in terms of extensions. Any application could check for supported extensions and offer different experiences. Or applications could be made to target different extensions. Thus an OS could choose to implement say only core extensions or more advance ones: such as extensions for 3D graphics.
