The QED programming language is a take on the age-old GUI problem, for those who still consider it unsolved. The design and implemention of a GUI application is still more complex than a text-based app, while exploding the number of lines of code.

However, a programming language that perfectly integrates GUI core principles in its fundamentals may mitigate this problem. This is the rationale for QED.

Without further ado, here is how these GUI concepts get gradually infused within the QED language.

Let’s assume as a starting point that QED has a basic syntax close to C for flow keywords, primitive types and function declarations.

Unlike C though, QED has the concept of a class that is declared just like a function, except for an uppercase first letter in the name to make the distinction. These classes can be instantiated with new. Instance members are accessed with the dot operator.

The QED classes are designed like functions because we can also invoke them as such. Therefore, classes have a dual nature as both types and functions.

Instantiated classes can also provide return values as events. When a QED script is done, it enters an event loop (a first fundamental GUI concept!). Adding a event handler with the -> operator on a class instance allows the event to be processed in the event loop.

Unlike plain function calls, the return statement must be invoked to exit class calls. If a call does not encounter return in its execution, it also enters an event loop, waiting for an event that will eventually call return.

The real usefulness of this dual nature (call/instantiation) first applies to QED native classes, which are wrappers to asynchronous JS calls. The QedTimer native class, for instance, can be called with new (asynchronous) or without new (blocking). No need for an external async/await mechanism.

This introduces another fundamental GUI concept, parallelism. GUI components are parallel (asynchronous), whereas forms/dialogs are blocking (synchronous).

We’ll present live examples of this soon but first, we need to introduce the last fundamental GUI concept, the UI definition.

For a GUI element, you first write your code, if any, for its business logic (model/state/…). Then you can write GUI code using a tree of markup UI elements such as this one below. Each time the application enters the event loop (at an unfinished class call, at the end of the script or when events are processed), the UI defined in markups is refreshed.

To encapsulate a business logic/UI markups combo into a component, just wrap it into a reusable class. Any class instantiation becomes a component. Let’s package the previous countdown example as a reusable component (or course that also applies to any well-known GUI elements such as buttons, check boxes, lists…).

To create various forms, just like for components, encapsulate their business logic/UI markups into a class, but use blocking class calls to invoke them as forms. As an exercise, let’s define a recursive dialog form.

You can have any number of overlapping dialogs, as they are directly linked to the class call stack.

Here’s hoping this overview gave you a clearer idea of QED. By fully integrating GUI concepts, QED enables the smoother development of sophisticated GUI web apps!

For a more detailed description and other cool features of QED, please see the the tutorial.