The USS Quad Damage

We can see that "applications" actually start coming together like LEGO blocks.

If you think about modern operating system design, most of the action is in the mobile space, and the moves in mobile space are clear: Applications are installed by the user, not by root. The phone does not trust the user. The user does not trust the apps (although they still manage to steal all the users' data), and the apps do not trust each other. Everything is kept piecemeal, separate, isolated. There are gates and checkpoints. Sharing data is hard.

This has actually been part of the “dream” of OS design and research — good separation between applications — for some time now, but shifting a paradigm like this requires a whole new playing field, which smart phones provide. The reasoning here is simple: applications are proprietary, so they cannot be trusted. The operating system needs to provide a solid base, so the user cannot be trusted to make changes.

If we look at Ubuntu Phone it has the same attitude. It is building a “solid base” on top of which applications are installed, all of which do not trust each other, nor the user.

But free software isn’t like proprietary software. The unix principle of “do one thing and do it well” marries perfectly with free software, where you can read the source code, compile it yourself, and connect it together. When writing free software, part of the thinking should be how everyone can work together to a common goal, and how we can take advantage of the freedom. This freedom engenders trust — trust between the applications, between the user and the operating system — which dramatically influences the design of the entire system.

If we think about a distribution like Debian, if we use free software, many people have put this software together, are working together, and the functionality of the software is known end-to-end, even though you may not have everything installed. The contents of the “app store” are similarly created and shared by trusted parties, their work is transparent.

Think about Gnome for a second, and what it means. Originally it was the GNU Network Object Modelling Environment. Really, the purpose here was for it to get apps to talk to each other. As time went on, Gnome realised that really, it was becoming a bloated framework that did too much, and began to split it’s work up into small libraries and services. These are used everywhere, even if you’re not in a Gnome environment! Ultimately, their role is really to be the “common language” that UI apps use to communicate with one another. Since we’re in an environment of trust, there may not be any code involved here!

I’ve been thinking recently: what would Gnome 4.0 look like?

• Firstly, most of the “actual work” should continue to be done in a library and / or a service. Luckily this already happens — with libraries like GStreamer or library / services like Telepathy. This ensures that the UI is simply a facade, and a particular task could happen with a similar CLI tool.
• An application should no longer be a monolithic thing, rather an Application Fragment (AF). Each fragment runs in its own process.
• Application Fragments should have inputs and outputs. An AF can “ask for” an input to be filled, or can ask for an output to go somewhere. We call this “share”.
• There should be an Application Container (AC), which manages AFs, but it might not know what fragments it is managing specifically. The Gnome Shell as it currently stands should be an AC. An AF might also be an AC. A terminal might be one of these cases.
• These inputs and outputs should be satisfied by putting messages on a bus, such as DBus. The (nearest parent) AC should look up the MIME type (or similar) of the message, and try and fill that with an AF it knows about. The actual data should be streamed using message passing.
• An AF should also have a “context” which it gets initialised with. This should likely just be a YAML or JSON stream fed into stdin. before exiting, the AF should emit a context which can be used for the next invocation (if nothing is emitted, then the existing context will be used). Several contexts might exist, including a “null” context where no data is fed into stdin. Several AFs might be running with different contexts.
• The AC controls the contexts of the AFs appropriately.

Let’s look at some examples:

• The “save file dialog” is simply an application fragment which handles generic file output. A separate AF would simply “share” data to a “save file”.
• The “settings” of an AF might be an input. A settings AF could output settings data for an AF. It would only need to know the schema of the settings, not the individual application in question!
• A terminal application might output an image, which the terminal emulator can handle, or perhaps it gets percolated up to the Shell. In this way we can implement something similar to what Termkit was attempting.
• An image could be viewed with one AF, but edited using another AF. Granted this would mean tight integration between the two AFs (very specialised sharing of data, or sharing a very specific message stream), but nevertheless this would basically be an image viewer normally in which you could temporarily “inject” an editor.
• A tiling AC which contains a traditional style “application” with a file browser in the left window, an editor in the right, with additional tools as flexible AFs. A text search box that could work just as well in a text editor and a document editor.
• Clipboard as an AF. You select data and “share” it straight to another app, or can "store in clipboard"

We can see that “applications” actually start coming together like LEGO blocks. Small, self contained ideas that do one thing and do one thing well. They have trust in their ecosystem that it can provide the other parts that they are after. They have trust in other applications that they can communicate with them properly and that they are not malicious, and they have trust in the user. It’s a virtuous cycle which means applications get functionality that multiplies exponentially and organically.

How might we present applications? Maybe a bit like the cards that Google is using: These are small, interconnected, and solve that problem of “doing one thing well”. In an earlier Gnome 3 review I suggested that nature ought to be a theme. This still makes some sense, with “vines” connecting AFs together. Perhaps these are like fruits or leaves that come off a tree trunk. You sort of expand that tree as you launch more AFs, or “prune” branches as tasks get completed. Maybe completed tasks get turned into branches, and later you can go back and change what you did. New tasks are like saplings.

Whatever it is, we should be aiming for authenticity with the framework we have as free software developers. The current model of copying proprietary software does no favours to the movement nor does it take advantage of the places where the movement excels. As I think forward to what Gnome 4 could be, I’m hopeful that it will emphasise the ideas of trust and sharing that make the free software community unique.