Rethinking Reticulum

In the world of communication, mesh has slowly started to grow out of it’s niche as something radio amateurs use. It is becoming something ordinary people use on a daily basis from a variety of devices. This is largely thanks to systems like Meshtastic, a message stack that helped make this type of off-grid communication accessible to everyone, not just the tech savvy.

Mesh what?

The first time someone mentioned ‘radio’ I automatically tuned out of the conversation. As a child of the 70s and early 80s, my mind conjured up images of our old neighbor tinkering away in his garage, maintaining bulky WW2 surplus radio equipment (and a huge antenna on the roof). That is how ‘radio’ looked like when i was a kid, and I honestly have not seen much of that since.

Mesh devices comes in all shapes and sizes and have become wildly popular

As the conversation progressed into software however, that’s when I started to pay attention, because the features that was outlined was (to be blunt) the recipe for a truly anonymous, ownerless network. One where there is no central authority or organization like we are used to with traditional internet.

And that’s when I discovered that mesh devices have little, if nothing at all, in common with the bulky old amateur radio equipment i remember. And also that mesh communication is not limited to radio. It will happily operate over Bluetooth, wi-fi and ordinary tcp.

Community networking

First, the devices these protocols were designed to run on are tiny. Seriously, they are no larger than a pager from the late 90s. Small devices you can clip on a belt or a backpack.

Secondly, mesh radio is purely digital. You can think of it as a a device designed to send small chunks of data within a radius of 10-15 km (depending on device type and signal strength). So we are talking tiny devices, surprisingly long range and coverage, no service fees, and you can even write your own software for them. You can implement your own protocol if you so wish, thats the whole point.

Meshtastic alone has monumental coverage in both the US and Europe, this map is just a small part of it

The reasons mesh communication has taken off around the world are many. First there is privacy, secondly there is mobility, and thirdly we have cost. People who like to go hiking in regions without GSM coverage use mesh all the time. This allows them to communicate with friends and family within a 10-15 km radius regardless of gsm coverage.

Since the devices are small people usually just attach them to their backpack or belt, pair them with their phone over Bluetooth, and use one of the many mesh messaging apps to send text, gps coordinates and even audio.

The reason it’s called ‘mesh’ is because these devices cooperate to extend their range. If my message cannot be delivered directly to you, but there is someone between us that can reach you – then my message will be sent to that middle-man’s device, and then re-broadcast from him in order to reach you.

Messages are heavily encrypted with modern certificates, so the data is useless unless you have exchanged keys first. So there is no danger of people grabbing your packets and snooping inside them. It would take years to brute-force crack such messages. Especially if you apply 256 bit encryption, or add your own ciphers on top of that (what is called a crypto-pipeline, several ciphers daisy chained together, and the data goes through each before being sent).

Message delivery can also be done over ordinary internet. If you have wi-fi available or use your phone’s data, messages are no longer limited by radio range. The message will be delivered over MQTT either directly, or to a node closer to your location. Which is pretty clever.

The software, not the hardware

As fascinating as mesh hardware is, it’s not really the subject of this article. What is more interesting is: what happens if we take the software for mesh networking and use it as the backbone for chat services or data transport on the internet?

Quartex Communicator, here showing the mail tab

On the mesh market there are currently 3 software stacks that are popular (I am sure there are more but these 3 stick out as the most widely adopted):

Meshtastic
Meshcore
Reticulum

Meshtastic is probably the software that put mesh networking on the map for non technical people. It is easy to use (no more difficult than sms), easy to flash onto a new device, and still has the bulk of the userbase.

Meshcore is relatively new. As far as I can tell it was created to deal with some of the shortcomings of Meshtastic. It has smarter message delivery and optimized routing. It creates less noise at the expense of needing a bit more infrastructure is probably a fair assessment.

The final one, which is the system that caught my interest, is Reticulum. This is not just a message framework, but something that could be used to create a new type of network. In many ways it’s the building blocks of a truly anonymous ‘internet light‘. And unlike the others the low-level packet protocol itself is designed around anonymity and military grade encryption. Encryption is not an after thought with reticulum, it’s intrinsic to the system right down to your identity hash.

Reticulum has got a reputation for being difficult to learn. Most of the apps for it, like Sideband, requires the user to be somewhat technical (but not that much). But this is starting to change with Android apps like Columba, which has done a great job in making Reticulum user friendly and more accessible.

Agnostic design

Reticulum is transport agnostic by design. It does not care how messages are delivered, as long as they are and replies comes back. So reticulum will happily work over TCP, UDP, Websocket, mesh radio, Bluetooth -and probably even carrier pigeons if you have enough of them.

Reticulum is designed to be transport agnostic. It does not care “how” as long as its protocol is followed

You can think of Reticulum as a cake with 3 layers. At the bottom you have what is ultimately reticulum itself, the core that sends frames and datagrams and makes data transport possible.

The second layer introduces transports, which is basically channels the core can use to send and receive data. TCP is a transport, Websocket is a transport, Mesh radio is a transport (and so on). As long as somebody implements a transport object according to specs, reticulum can use it.

The third layer is where things become interesting. This is where high-level protocols exist. You have a mail protocol which implements a message format more or less similar to email, including binary attachments.

You have news-group support (just called groups) which, if you look at the specs, is clearly designed to enable usenet like groups, with threads, replies, sub-replices and so on. This feature appears somewhat abused in other apps. Most apps display group content like a feed (like a whatsapp feed or facebook feed almost), but if you look at the protocol it’s pretty clear that it was designed as classical usenet.

Another high-level protocol is Nomadnet (a.k.a ‘sites’) which can in some respects resemble http, but it’s designed to be minimalistic. The standard document format is not html, but something called Micron. If you ever used a BBS back in the day and remember the console UI’s and ascii art pages — well, thats pretty much what Nomadnet pages are. The content is designed to work well over radio.

Nomadnet pages are quite fun to discover, it’s a bit like going back to the mid 80s, love it!

Having said that, there is nothing stopping you from serving html. Opening a page ultimately resolve to a file-request. That it’s a Micron page is ultimately down to interpretation by the client and what it expects. Micron pages have the *.mu extension, but you can just as easily serve text-files, an mp3 or whatever you feel like.

Not limited to

What I find exciting about Reticulum is not so much the high-level protocols that are in place at the moment, but rather that the software-stack itself is inviting. As long as you follow and respect the underlying reticulum core protocol, you can build your own high-level protocols as much as you want.

Obviously you want to avoid flooding the network, it’s important to avoid being a burden on a hub or node. But the entire point of Reticulum is to ensure freedom of communication and make it possible to establish peer-less services.

The Quartex Communicator is not a lightweight python project, its a small, native multithreaded monster

I decided to implement the reticulum protocol in Object Pascal (took me a few weeks to say the least) and do a little experiment: Without looking at the other clients, how would I interpret the protocols purely from the documentation?

I mentioned briefly that Reticulum groups have features that mimic old-school usenet groups. These were extremely useful back in the day, and I honestly dont understand why Microsoft removed them from Outlook. Either way, I did notice when i googled the subject that others seem to render group feeds more like a whatsapp or facebook. Which is borderline criminal in my book, it’s such an elegant design that it should be given more attention.

Limitations of groups

One strange thing I found with groups, is that the way they are used does not really reflect the documentation. The original author clearly defined a system with a lot more functionality in mind than what has been delivered so far.

The way people use them appear more like an organizing principle between ‘a group of people’ than it does an actual usenet usergroup. I could be wrong here ofcourse, but there is a disconnect between the specs and how people actually use them in real-life.

But if you look at the specs you find things like: thread fields, sub reply (nested replies to a top thread). That is how usenet groups operate. The original author must have thought about that otherwise there would be no need to have such fields.

The way people bypass that 1-hop rule is through replication nodes. Nodes that purely copy messages further. Since this replication happens on node/hub level, you don’t violate the 1-hop rule. Because you as the user is still just connecting to a hub, which is 1-hop.

This 1-hop rule sounds strange if approach it from a TCP point of view, but it makes perfect sense for a mesh-radio. To help build a mesh people often setup repeater nodes to cover an area, nodes that simply re-broadcast messages to extend coverage. The only way to ensure that a message doesn’t repeat indefinitely between radios, it keeps a hop count. A value that is increased by 1 for each broadcast, this is called a hop.

If you have a team of say 10 people that are searching for a missing person up in the mountains, then creating a group that unifies communication between their mesh radios is a natural feature. You dont want random messages repeating for hundreds of miles. It only becomes weird when you take the same logic and apply it to TCP.

Global rooms

I decided to create something better suited for global communication that I have just called ‘rooms’. More or less the same functionality as messenger chat. Each message is replicated to each member in the room. My model also introduces roles, where the group creator is ‘admin’. New members are assigned a member role when they join, but only the creator can be admin and have the right to kick members from the room.

The rooms feature gives you ordinary chat, but also group audio calls!

The benefit of this model is that:

It does not flood the network, messages are 1:1 between the members only
Metadata is handled by the software that implements the room protocol
The room exists as long as the metadata is carried by a member, so even if the creator’s node is offline, the room still exists.
Messages appear as a chat feed, typical of mIRC and other apps. It’s meant to be X number of people talking, not per-subject posting.

Persistent delivery

One of the challenges with a peer-less network is that you cannot persist data. With email you basically hand over your data to a middle-man. The message is shipped to the recipient’s middle-man where the recipient downloads it from.

Reticulum has a similar feature, called ‘propegation nodes’. These are servers purely designed to deliver mail messages. But by default you will always try to deliver a mail message directly, the message propagation should only kick in if one of the parties is not online.

But what if you dont want to use a propagation node?

I think I have come up with a pretty good solution. This is not a protocol but rather a feature of my client. If a message cannot be delivered, it is given a state of ‘in-transit’. It will remain in your Sent Messages folder, but will be marked as not delivered.

Persistent delivery means the client will try again on interval. The interval can be set in preferences.

Once every hour the client checks if it has undelivered messages in your storage vault, and it will attempt to deliver them. It will try once every hour for 14 days. If the message is still not possible to deliver, it is marked as ‘undeliverable’ and taken out of the loop. You then have to manually go in and right click on it, and hit ‘Send now’. This puts it back into the loop for another 2 weeks.

I call this ‘persistent delivery’. It avoids storing data with a middle-man, and as long as you have your client running the program will deal with it automatically. So unless your friend is offline for more than 2 weeks, it will get through.

Or you can just pick a propagation node from the list of known nodes the client has discovered. It’s all heavily encrypted anyhow so there is that.

Adding TOR

A month or two back I did a port of TOR (with much help from Grok to deal with the C header conversion and encryption logic) to object pascal. And this seemed like the perfect spot to use that code for something interesting. So where Reticulum anonymizes your identity, TOR anonymize your IP and location.

Built-in TOR support with no dependencies is definitively a bonus

So after much swearing and late nights, I finally got my TOR port bolted into the reticulum client, and added an option for connecting through that. And so far it has worked brilliantly. The beleth server doesnt seem to like TOR exit nodes, but im not sure if that’s something done on purpose, or if it’s an ISP refusing to forward the TOR frames.

Chat service

On the plan for the Quartex Media Desktop is a chat service. I had originally drafted a chat protocol purely for websocket, but having spent some time with Reticulum – I think we will adopt that instead. It is a perfect fit for our desktop model, it’s lightweight and easy to work with – and it allows people that use our desktop system to access a wealth of existing reticulum resources.

The reticulum client I have coded was done using native code, so we will need to port the core of this to Quartex Pascal before we can isolate it as a component. For that to work smoothly we need to get parts of the codebase we currently use to build the IDE ported first. So this will not magically appear over night.

Living topology map

Reticulum is 100% privacy oriented which I love, but you can also send geo-location if you want (you can turn that on/off in preferences). There is nothing nefarious about having a reticulum node on your roof or clipped on your backpack. It is a affordable, exciting and energy efficient way of communicating.

Nodes that do send geo-location are typically infrastructure nodes, nodes that are permanently fixed on a roof, in a window or on a wall somewhere. And they are everywhere in the world!

I added a cool animated map in our client that shows announces. So whenever a hub announces itself, you get a little animation between it’s nearest nodes. A node usually send an announce every 30 or 60 minutes.

Basically I do a 3×3 probability matrix of how a node ‘could’ be connected or reach another. But it’s purely speculative so don’t read anything into it. I just love the idea of a living mesh topology and added the animation. But the animated lines between hubs meant to symbolize data-flow is not verified truth, just blind probability. I make no distinction between tcp hubs and radio hubs, and the distances involved makes it highly unlikely that signals would travel that far.

I should underline that 99% of reticulum users will not send geo-location, so the map will never show the tens of thousands of active nodes out there.

Torrent and git support

One of the fun discoveries I made with Reticulum, is that a lot of people host their git repositories purely over reticulum. Some times as a protest against people who just scavenge github repos, but also out of principle. If you want reticulum code then you should be a part of the community. As a man of principle myself I find that ‘rebel’ vibe very welcoming. People are sick and tired or surveillance, censorship and corporations harvesting personal conversations without permission.

There is also a lot of torrent links, especially for Linux distributions. I absolutely love that! If normal internet should ever go down due to war, conflicts or natural disaster – reticulum users will still be able to communicate and transport important software. It will be slow as hell downloading 700+ gigabytes over LORA (lol, yeah i know) but at least it will be possible!

And Lora+ was released back in December last year which is 10 times faster than the devices most people have today. Most low-end reticulum radios operate with 500 byte packet sizes. The mid-range devices typically offers 1k packets. But Lora+ gives you 4k packets.

And then there is Wifi-Halow which is something completely new. It is basically a Frankenstein technology, an unholy marriage between wi-fi and lora mesh radio. So it’s long range wi-fi with the same signal modulation as mesh radio (read: can travel far, good penetration of matter, can reflect around obstacles etc). I have two such devices myself and you get modern internet speed for 2 kilometers on ground level (not massive data, but enough to watch Netflix and YouTube 2km from my house, that’s pretty damn good!).

Give this tech 5 more years and I think we are going to see mesh devices with the same range (10-15 km) as today’s mesh devices, but with significantly better bandwidth and data transfers. A few thousand of those nodes around a country, and you basically have a free, unstoppable, impossible to police, network driven purely by the community.

Since i already implemented a Torrent client for the Quartex Media Desktop, I just ported that from QTX to Freepascal and added it to our Communicator. This makes like a lot easier. When you are on the Debian Micron site, clicking on the Torrent link will trigger a download – and you can start, stop, pause or delete it if you want.

Data is stored in the cryptographic vault. All messages, rooms, chats etc are all stored in the same single-fine vault. This uses crypto pipeline tech and is rock solid. If nobody explicitly knows your key-data or key-file, it will take 10,000 modern computers roughly 10^17 years to brute force their way through. And that would just give them the first layer, a crypto pipeline has many.

Final thoughts

If you like the idea of your own private network, one that you can run over mesh radio or ordinary internet, then this will be a stellar addition. You can also use it for much more than just chat. Sensor data between an outpost and a main hub would benefit from this as well. Reticulum ticks all our boxes and we really love the community behind it, they have the same creative spark that we find in the object pascal community. Where the question is not always why, but how.

Oh, and the amount of encryption in this thing is off the scales. Reticulum is designed around encryption at the very core. Your identity is a single hash + nickname, and that’s it. I followed suit by making sure data-files are likewise encrypted with the same military grade encryption. So it’s pretty much bolted shut. And with no external DLL’s as dependencies – it’s going to be very difficult to breach privacy in any meaningful way.

Live form designer

Quartex Pascal operates with a representative mock designer where your widgets (controls) are visual boxes you move around, align, resize like any form designer. The reason we opted for this is simply because HTML5 is extremely costly to render. But that is about to change.

Live rendering

The IDE now sports a headless rendering process, allowing us to turn your form designs into a WYSIWYG surface. This is still very early work, but the render pipeline is finished and we are optimizing it where it’s neeed.

As you can see from the picture above, it renders 1:1 and you get exactly what you will see at runtime (the overlapping form is runtime).

The margin conundrum

The Quartex RTL implements alignment support, just like people are used to from Delphi and Lazarus. While the layout engine is easy enough, there are edge cases where the layout can drift. This typically involved external libraries where you have a piece of code that applies margins or padding ‘ad hoc’ without abiding by the CSS. Or alternatively, where you have CSS rules that enforce margins that are immutable (that QTX cannot easily override).

In order for the RTL to fit into how JS and HTML5 developers typically work, we had to do a minor, scalpel change to the RTL and how the TQTXWidget.PerformAlign() method align widgets.

The challenge is that the browser can operate with two completely separate X and Y axis, which depends on the boxing model used by the document, as well as how we obtain the bounding rectangle of a widget (read: the not so subtle difference between BoundsRect and ClientRect).

We have done a full audit of the RTL and pinpointed 5 spots where we had to slightly adjust the code. These are quite small adjustments, not something people would notice straight away – but it’s worth mentioning them.

What have we changed

The RTL operates with predominantly absolute positioning, but supports all the modes that HTML5 has to offer. But since HTML doesn’t have any “align” property like we are used to – and that means we had to compensate for it when widgets are aligned.

If the CSS margin of left|top is set on a widget, then we have to subtract that together with any right|bottom margins to get the correct edges. This part has been obvious all along, but the consequences for the widgets that make up the RTL has made us reluctant to alter it.

This has now been fixed. We let HTML5 do the heavy lifting and thus we avoid having to adjust between two separate axis.

Scalpel work

Most developers will not really notice this change. It is minor and not really visible from a form-designer centric view. All your forms will work exactly like before, there is no data changes involved.

If however you have written your own custom widgets where you have adjusted for the old right|bottom margin, then you need to update that code.

It’s a one-liner, but it matters since margins can radically affect your layout.

AdjustRect is your friend

In Delphi and Lazarus there is a method called AdjustClientRect(). This method is for exactly the same reason, namely to adjust a rectangle with the border-size and padding. Ours only differs marginally.

Our RTL likewise has this method, cleverly disguised as AdjustRect() in the border object. The border object is intrinsic to TQTXWidget, so it’s always available. And just like you would call it when dealing with the client region in Delphi, the same applies here.

procedure TMyWidget.Resize(Orientation: TQTXOrientation);
begin
  var lBound := Border.AdjustRect( ClientRect );
end;

Benefits

The benefits is that margins work like they should under aligned widgets.

The widgets stay within the rectangle the alignment has allotted for them, and the margin ‘eat’ of that space, rather than magically growing into sibling space.

This change matters a lot for the live rendering, as it needs to know exactly where to place the bounding rectangle, and it must match 100% on all edges.

Generics, RTTI, a new compiler

The past couple of weeks have been interesting to say the least. Those of you that follow us on Facebook or Discord already know what we have been up to, but for those that are not in the loop – here is a quick overview.

Up until this point we have used DWScript to parse and generate our program model (the abstract symbol table). This model is then processed by the code generator, which turns your program into lean and mean JavaScript.

But, starting with the next update, we part ways with DWScript.

Our new compiler merges some of the core features that makes DWScript so wonderful with our own ideas. Ideas which gives us the pieces that have been missing. Glaringly so.

Full support for Delphi style generics
Full RTTI (runtime type information) compatible with Delphi
Almost twice as fast compilation
Binary records
Variant and Interface support for wasm

The result of all that work is that we have reached what is known as ‘compiler singularity’. The stage where the compiler is capable of compiling itself.

As i type we have the QTX compiler running in the browser and node (!), something that was at least 2 years away on our previous timeline.

Binary record types

Pascal records (same as struct in C/C++) under QTX compile to ordinary JavaScript structures (read: raw objects). And for normal web applications that covers most programming need. You can easily serialize them to JSON, easily load them from your server. JSON is the universal glue of all things web.

Our users are producing widgets and web apps at a staggering rate. Picture: Ed Van Der Mark’s scientific calculator widget

But when porting code from from native languages that makes heavy use of records, records that are meant to be written verbatim to a stream or memory location, JSON becomes a problem.

Porting code to the web

I recently ported Reticulum, a system for sending data via radio devices (similar to Meshtastic and Meshcore) from C to object pascal. This codebase talks to the mesh radio over serial (USB), and involves a low-level packet protocol similar to TCP/IP datagrams. In order to be compatible with other Reticulum nodes (be they radio devices or online servers) three quite complex protocols had to be implemented, the next depending on the previous. All of them based on record structures, bit-masks and native behavior of fields and values.

Porting Reticulum from C and Python to object pascal was a challenge, but rewarding

Needless to say the extra work to get Reticulum running on QTX would be monumental. There are some 60 data structures involved, and each of them would need a factory function, a reader function, and a writer function. That’s 180 boilerplate functions just to handle data.

The solution to this is to make binary records intrinsic to the compiler. To make it something the compiler knows and have a strategy for.

Packed records

We have recycled the ‘packed’ keyword to signify that a record type should be sculpted as binary. Whenever you use such a record the compiler will create a buffer object uniquely for the instance. Every read or write to the record fields are resolved to the buffer’s own read and write methods matching the field type. All of this happens automatically, you don’t have to think much about it.

type
TMyMessage = packed record
  rId: uInt32;
  rSize: UInt16;
  rX: uint8;
  rY: uint8;
  rlabel: string[255];
end;

And yes, writing binary records to a stream or buffer comes with this as a natural consequence. Our RTL already has a rich set of classes and methods for working with binary data. But this makes QTX feel “almost native”, even when you target JS.

Generics

This is probably the feature that will have the most impact, as it dramatically changes how we write maintainable code. I have already isolated several aspects of the RTL that will be reduced by as much as 60% as a consequence.

A universal dictionary is now reduced to:

type
  TQTXDictionary<K,T> = class( TObject )
  private
    fLUT: array[K] of T;
  public
    property  Count: int32 read ( fLut.Count );
    property  Keys: array of K read ( fLut.Keys );
    property  Items[const AKey: K]: T
      read  ( fLUT[k] )
      write ( fLUT[k] := Value) ;
    procedure Clear; virtual;
  end;

A dictionary of this type has technically always been a part of QTX through associative arrays. So you could achieve something similar with:

type
TQTXDictionary = array[string] of TMyObject;

The difference is that the array declaration needs full typing, so the key and value must be defined. The generics class will accept any intrinsic datatype as the key, and more or less any type as the value. That’s the beauty of generics, that you isolate behavior unbound by type.

Any of these are valid:

var dict := TQTXDictionary<string, TQTXLocalDisk>.Create;
var dict := TQTXDictionary<int32, TQTXPixmap>.Create;
var dict := TQTXDicionary<THandle, variant>.Create;

RTTI support

RTTI (runtime type information) is a powerful feature that let’s you examine datatype information at runtime. There are a myriad of ways this can be used to improve maintainability of your code, but where it really helps is object persistence and serialization.

The QTX RTL already have a strategy for persistence. In the class TQTXPersistent we introduce three methods: ReadObject, WriteObject and Assign. Since the target of our persistence remains JSON, this strategy has been manual, where you override ReadObject and WriteObject and process the fields in question.

Persistence of components outside the IDE have not played a part in our codebase so far. We don’t want to load design-files for forms or components, and instead we convert our layout’s to code, and compile them with your form constructors.

With RTTI in place however, we can implement standard persistence of published properties for any class that inherits from TQTXPersistent. Almost no class in our RTL use this, so adding the same persistence that Delphi offers is easy.

TQTXPersistent will soon do more or less the same as Delphi or Lazarus: enumerate published properties and serialize accordingly. And with that we no doubt have to add a TFiler “ish” mechanism for handling exotic datatypes (e.g binary properties, like TStream, TManagedMenory etc).

Summary

As you can see we are going full steam ahead! Quartex is growing on a weekly basis and we are quickly catching up with the big boys in terms of features!

With the new compiler we might even look at adding llvm support and produce native binaries, but for now focus in purely on web technology.

WASM commandline compiler

The Webassembly (wasm) command-line compiler is ready for an alpha flight and we will be testing it over the weekend. Once we see that it passes our test harness and safety scripts -it will be available to customers to play with.

I was surprised at how much survived from the system namespace. The most obvious loss is TQTXJSONObject which affects TQTXComponent and widget serialization at runtime.

The commandline compiler will be available to our customers shortly

Since our RTL does not use this feature extensively and it only affect Ragnarok messages, I doubt you will notice that it’s not there. All TQTXComponent based classes (which includes TQTXWidget’s) can serialize to/from JSON, but we have not implemented it in each widget yet to avoid the overhead. Eventually we will add it, which opens for loading and saving of DFM’s at runtime – but it’s hardly a pressing matter.

What to expect

Webassembly is closer to native code (machine code) in nature than it is Javascript. So where ordinary QTX has soft edges and a forgiving natire -webassembly is more like Delphi or C/C++ with little middle ground.

Under Webassembly the datatypes are real. Under ordinary QTX the datatypes such as Int32, Int64 etc all resolve to a standard Javascript variable. The datatypes are there to help the compiler resolve ambiguity and to initialize the variable with the correct default value. They are also there to help you work with familiar type names.

Webassembly does not allow for such softness, so if you define an Int32, you get an int32.

No variants

Webassembly lacks the variant datatype. This is used heavily under QTX’s DOM and Node namespaces to carry object references. So there is no variant datatype available at all since that would mean reverse engineering the entire multi-type infrastructure.

A large number of units from the system namespace have been ported

While it’s definitively doable it will just result in bloated code. Every method needed to work with the datatype would have to be linked in, and the compiler would add extra calls to these whenever you touch a field or variable of that type.

We might add variant support later, but right now it sort of defeats the purpose of Webassembly modules (imho).

No generics

QTX does not support generics in the conventional sense, except for promise objects. Eventually we will add full generics support for both JS and WASM, but its not a high priority since array objects does a great job of being collections. There is much more to generics than just typed collections of course, but the immediate benefits are covered by arrays (all arrays are objects under QTX, which has the same methods as a TObjectList<T> under Delphi or Lazarus).

The one place we do have generics, namely for JPromise<T>, did not make the transition. This binds directly to the JS codegen and would need heavy refactoring.

Promise objects makes little sense under Webassembly anyways, as it is an async control mechanism. Webassembly is blocking, just like native languages. It could be useful when calling out from Webassembly into the DOM or Node, but that will have to wait.

How to approach it

In our view Webassembly is best approached as libraries; like writing a DLL and isolating methods that would otherwise take a long time or be very slow in ordinary JS.

On top of my head the following are perfect candidates for webassembly:

Hashing large chunks of data
Compression and decompression
Encryption and decryption
Graphics processing such as filters and effects
Audio processing
Pre calculation

We could have gone completely overboard with this and allowed Webassembly classes to be exposed to the host, like Microsoft has done. But the cost would be absurd. It would mean that the code generator would have to emit a fake class, a proxy, that calls into wasm space in every method – again leading to massive bloat and binaries.

If we ever make such a mapping we would try to make exported classes purely external, just like we do for the DOM and NodeJS today. But that will have to wait.

Why Webassembly exists

Javascript was originally purely interpreted and very slow. Eventually it became JIT compiled (just in time compilation) which translate as much of a script as possible to real machine code. However, due to the dynamic nature of Javascript it is impossible to pre-compile an entire script.

So most Javascript runs in chunks, where some parts are pre-compiled and others are interpreted. This is why writing fast Javascript can be very difficult. Everything hinges on what datatypes you use, how you work with values. and what references you pull in and when.

The only way to solve this was to introduce a runtime with the same rules as native languages: strongly typed, linear memory, a proper stack -and a fixed and standard instruction set.

Since raw Webassembly is very low-level stuff it’s not for everyone (you wont have to, we have done it for you!). Writing raw Webassembly is like writing x64 or ARM assembly code (more closer to ARM than x64 to be honest).

Your code have to allocate and manage the stack from the same memory segment as the code, if you want classes and objects you have to implement your own stack-page logic just like a native compiler, and you likewise have to manage memory use and keep track of available segments. So it’s pretty dense stuff.

The result though, is that the entire wasm file can be converted to real machine code in a single swoop by the host! There is no mixed bag of native and interpreted code chunks, and that means the code runs very close to native speeds (performance is roughly 90% of stock C/C++).

The only speed penalty is when you call out; out of the wasm space and into the DOM or NodeJS. This is why I am trying to keep such calls at a bare minimum.

As of writing we only have two such cases:

Writeln() maps to console.log()
SetTimeOut() binds to the same function in the DOM or NodeJS. This function is used extensively in TQTXDispatch for scheduling future execution and is extremely useful

Everything else has been painstakingly re-implemented under Webassembly. Functions like Now() which returns a TDateTime compatible with Delphi and Freepascal is a pure implementation, it does not rely on the JS RTL or the host at all.

Again, we could have gone all in here and mapped up every class and RTL method under the sun, but the price would be bloat.

Having fun with Quartex Pascal

With AI at our disposal anything seems possible. At least if you know what to look out for. And as a fun weekend project we decided to port something that ticks all the boxes: namely a Commodore Amiga emulator!

The Quartex Amiga Emulator (QAE)

The Commodore retro community has no shortage of emulation options these days, but for the browser there has only been two options: SAE (scripted Amiga Emulator) which is a pure JS implementation, and VAmiga which is a webassembly Amiga implementation. There is also a third alternative that just dropped, a project called Copperline which is a cycle exact rust implementation that likewise compiles to webassembly.

Defender of the crown: the game that put Amiga on the map

For our port we decided to use SAE as our initial source believing that it would be easier, but we ran into some strange inconsistencies. So after much frustration we ended up peeking at the Copperline source and found a lot of solutions there. Like all computers the Amiga had it’s fair share of quirks and unwritten rules, things that makes writing an emulator more difficult.

One benefit however, is that we were not aiming at being cycle exact or 100% true to the original hardware. SAE does a good job at playing demos and games, and while there are titles that it struggles with – it manages to play the majority of titles you throw at it.

For the fun of it

Like many other European developers we grew up with C64 and Amiga as household names, and those computers hold a special place in our hearts. Personally I own several Amiga machines, both real and later FPG implementations, and they still inspire and remind me of a time when computing was fun.

Even by today’s standard the graphics is uniquely warm and vivid

There is a lot of Amiga in Quartex Pascal. We have tried to capture that free spirit that the Amiga represented; the spirit of “it can be done” and that realizing ideas and dreams doesn’t have to be difficult. The IDE houses concepts from languages like High-Speed Pascal, BlitzBasic and Amos. These were the languages we grew up with and that inspired us to become developers in the first place.

So this port is not meant to be better or worse than the emulators already available, it is more a testament to what Object Pascal is capable of, and that you can create just as complex and interesting products as C/C++ or any other language in the same family.

The very first game

The first game I ever played on the Commodore Amiga was Defender of the crown. This was without a doubt the game that put Amiga on the map. It was so rich in color compared to the 8-bit titles we knew, so vivid and fun to play, that I remember coming home to my C64 feeling somewhat depressed.

Needless to say I began a nagging campaign towards my parents, and eventually they caved and bought me an Amiga 1000. That was pure magic to me and i spent every penny of my savings buying Defender of the crown and Rocket Ranger. This was whole new world compared to the C64. A world where we had a desktop, icons, graphics applications, music applications and software at least a decade ahead of everything else out there.

Defender of the crown was the very first game I booted on the ported emulator – and it runs surprisingly well. There are a few quirks here and there that needs to be ironed out, but sound, disk drives and graphics are all in place.

Porting and legality

We have only put a weekend into the porting, but we are roughly 70% compatible with a stock Amiga 500. The moment OCS (original chipset) is covered – we will add the emulator to our examples folder.

After that we will get ECS (enhanced chipset) working, and finally bump it up to an Amiga 1200 with a 68020 instruction set. This is the computer that most people use when emulating so it seems like a worthy goal.

Defender of the crown: The strategy leaves a lot to be desired, but its a feast for the eyes

It must be underlined that we cannot ship the kernel files (the rom files). These are copyright and are still sold. So you will need to provide your own rom-files.

We will however ship the Aros roms, which is an opensource and free alternative to the official Commodore rom files. Aros is usually enough to run most games and demos, but there will be titles that require the official Commodore roms (1.3, 2.x, 3.1).

On the upside, with the code ported to Quartex Pascal, making optimizations and adaptations should be easy. It is a complex piece of engineering – but the difficult part taken care of.

Android virtualization

This weekend I decided to jump head first into a skunkworks project, one I have wanted to play around with for a long time. Namely: virtualization and framebuffer / audio streaming. In short, can we run Android in a virtual machine and fully integrate it into the IDE?

The answer is overwhelmingly: yes we can!

Qemu integration

Imagine you create an Android project in Quartex Pascal. You edit the project like you always do, but the moment you click ‘Compile & Run’ you are given an option: do you wish to run the project as usual in the embedded browser? Or do you want to fire up real Android and see how it behaves there?

My little test project: here running LineageOS (Android) for x64 headless, rendering to a custom control inside the testbed

You opt for the real deal, and the IDE does everything for you. It downloads the qemu runtime suitable for your system, it fetches a ready to rock Android distro, and it will roll everything back should anything go wrong (like your anti-virus finding it suspicious and blocking it).

When everything is setup the IDE shows it’s browser window – except now it’s rendering the Android display directly. No shortcuts, no SetWindow() hacks, no nonsense. A full implementation of the streaming protocol with a fallback to VNC rendering.

You never have to leave the IDE if you dont want to, and the debugger attaches directly to the Android webview inside the virtual instance. Breakpoints work exactly as they do elsewhere since we support the full Chrome debugger protocol. You get to see how your code behaves on an actual OS.

Rolling real APK’s

This little side-project aligns with a previous weekend project, namely to roll real APK’s from your compiled QTX projects. This is already done and is waiting to be merged into the main branch on our repositories. Some adaptation is needed, maybe a few days work – but its relatively simple stuff.

This is why you see the ‘Install APK’ button on the test UI above. This ships over the apk from the IDE and calls Android to install it properly. All automatic.

Works on all platforms

The setup routine I pieced together is smart enough to check the platform you are on, downloading the binaries and disk image you need. I added an override for emulation rather than translation (so you can emulate Arch64 on your x64 PC if you like, but there is no need for it. You will get a much better experience running x64 LineageOS on your x64 machine due to virtualization).

Here running x64 Linux (Debian) headless under the same interface

It works fine on Windows, Linux and MacOS. It runs fine on x64 and ARM. It also neatly integrated into the QT framework (which we use).

When will it be in the IDE?

It wont make it into this weeks update, maybe not even the one after that, but it’s definitively on our roadmap!

This is incidentally the exact same tech that we will have running on our Quartex Desktop. Where the virtualization runs headless server-side, while you enjoy whatever application or OS you fancy inside a QTX window.

So there is a lot of cool stuff happening in the lab these days!

Webassembly is here

I hope everyone has had a great summer and gotten some well deserved R&R. In Norway the weather is slowly turning darker and colder, and we are back in the labs at full speed. And we have great news for Quartex Developers!

Finally running

Webassembly (WASM) is probably the feature most QTX developers will be the most excited about, and it has been in the pipeline for quite some time. Already back in January of this year we finished the initial assembler and bytecode emitter, so this was only a matter of time.

What has been missing is to implement a new ‘codegen’ for the compiler, one that turns the AST model the compiler builds in WASM bytecodes rather than JavaScript. That is a massive undertaking covering a large corpus of classes, symbols and features unique to the QTX dialect.

The intrinsic functions have all been re-implemented in pure WASM

Thankfully Grok-AI and Claude has been exceptionally useful in dealing with all the boilerplate tasks and infrastructure. It helped us setup all the symbol classes and required scaffolding – leaving us to write the fun stuff, like the stack page layout, var param strategy, set implementation, lambda capture and all the small methods intrinsic (and fundamental) to the language. You know, those functions we rarely think about, like now() and TDateTime being compatible with how Delphi and Freepascal encodes the data.

Once the nitty-gritty was handled, the rest was a matter of doing what the JS codegen does, but in webassembly rather than Javascript.

So without further ado: yes we have a fully functional webassembly codegen, one that can spit out both wat (source code) and binary webassembly files. We also added a separate step that emits the JavaScript bridge, the “glue” code you include to make webassembly functions and procedures callable from your QTX applications.

To variant or not to variant

Anyone familiar with webassembly might have noticed that most compilers excludes support for the variant datatype. In Quartex Pascal variant is heavily used by the RTL and plays a huge part in what makes QTX integrate so well with web platforms. A pascal variant under QTX maps directly to a normal JavaScript variable, which means it can hold not just values – but also element and object references. So the variant datatype in QTX works more or less exactly like variants do in Delphi, including the capability to hold object references to objects and interfaces.

Webassembly however, is a completely different beast. It is by nature closer to real machine-code but with one crucial exception: there are no pointers, only weak references (or with records and class instances, offsets into a buffer). This means that datatypes like variant would have to be treated as a conditional record. The codegen would have to emit code that tags the datatype every time you write to the variable, and read that back whenever you use the value (otherwise it would not know how to interpret the data at runtime). This represents a significant overhead in terms of speed, and even then – it would not be compatible with variants coming from JavaScript.

Since the entire point of webassembly is speed, introducing a datatype that utterly defeats that purpose is counter-intuitive. There is also a question of how much use it would see? It is difficult to envision any scenario where using variant under webassembly brings any benefit. It might be that we add variant support later, but for now we dont support it.

New RTL Namespace

Webassembly does not understand the DOM, nor does it have direct access to the DOM or NodeJS modules. This means that any RTL function or class must be re-written to work inside the webassembly sandbox. That is a formidable undertaking, one we at least partially can look to AI to save time. But it will still take time to ensure the same behavior.

The aim is to introduce a new namespace ‘wasm’, clone the existing system namespace and all its units, and then convert every method that relies on the JavaScript runtime into webassembly. This will give our customers a solid foundation to build advanced and powerful libraries.

As of writing we have not started on that task.

Javascript bindings

As mentioned the compiler generates bindings automatically for you. All you have to do is mark your unit level procedures or functions with the external keyword, just like you would in Delphi when writing a DLL. The codegen picks this up and creates the “glue” needed so you can invoke the methods from JavaScript.

As of writing this is a clean Javascript (*.js) file, not a pascal file. But that will change shortly. We will emit a second file, a unit that gives you a clean pascal interface. Literally a drop-in solution to any of your DOM or Node projects.

What about classes?

Both classes, records and ad-hoc structures are supported. However they do not cross over from webassembly to JavaScript. We might expand ‘external classes’ to include WASM in the future – but for now you talk to your WASM through ordinary functions and procedures.

Inside the webassembly though, you can create classes, records, arrays and collections as much as you want. So porting Delphi libraries to webassembly that relies heavily on classes or records should be fairly straight forward.

This is more or less identical to how you would write and use a dll library in Delphi or Lazarus. Same approach, different paradigme.

Having the compiler emit skeleton classes that just invoke it’s webassembly counterpart would just result in bloat.

Early test version

We will be offering a command-line preview of the webassembly compiler for our customers sometime in the coming weeks. First up now is an update that fixes a few things, in the IDE. We have done a lot of work on the ARM / Linux build (issued to beta testers today).

A part of the update includes the SEE (sematic execution engine), a full chatbot engine ready to be dragged & dropped onto your forms or datamodules.

SEE is a chatbot package. It is not LLM but rather a classical NLP with some concepts borrowed from AI. It is far more clever than the old ‘chatbots’ and was created to be the hub for speech-to-text and text-to-speech projects.

With that out we will turn our attention to getting the webassembly commandline compiler into the hands of our customers – and when we feel its mature enough we will bolt it into the IDE.

Quartex Pascal 1.1.0.3 available

We are happy to report that Quartex Pascal version 1.1.0.3 is available for download! This has been one of the largest updates since the initial 1.0 release and contains a wealth for fixes, improvements and exciting new widgets.

Changelog

Important adjustments for the claude.md file which makes the AI check the RTL instead of going overboard with ASM snippets. Claude is amazing but it does love to fall back on raw JS unless you explicitly tell it that raw JS should be the last resort.
Fixed a critical typcast bug found in TQTXSplitter which caused it to only work when placed directly on a form. This was a simple mistake where we cast to TQTXWidgetContainer, but should have cast to TQTXWidget directly.
Fixed an issue with TQTXMoveObserver. This was based on a pattern provided by the now removed polyfill dependencies. TQTXMoveObserver now inherits from the generic DOM observer and watches for left/top changes applied to its owner. In most cases the move observer does not need to be active (it is off by default). It is quite a costly feature so only use it if you need immediate feedback about position changes.
Generates skill files that helps claude write QTX compliant code that uses our language dialect’s features. These files will be available shortly as a separate download.
Fixed and issue with claude sending garbage to the MCP. This is not an issue with our code. If you notice that it produces suspiciously large files, use notepad++ or GitKraken’s editor and delete the single line claude has messed up. In all cases so far it occurs when claude is generating comments and have multiple agents accessing the same source-file. Its always one massive line of garbage – which thankfully makes it easy to fix.
Implemented missing DOM delegates, so we now have delegate classes for all the events the DOM has to offer (clipboard will be in the next update or hotfix). This has resulted in a whopping 24 new delegate classes in the RTL that wraps everything from drag & drop to multi-media events, animations and message handling.
Updated all “partial class” definitions that expand TQTXWidget with AddXYZDelegate(), adding helper functions for all 24 new classes. I am pondering if we should instead expose these via a single interface property. They do fill up code suggestion when visible directly on the widget scope.
Cleaner abstraction for TQTXRamDisk. The base-class is now in the “universal” package, and then we inherit out specific Node and DOM versions from that. Next up is TQTXLocalDisk for access to the real filesystem. This runs only under NodeJS and access is done via websocket / Ragnarock messages. After that we move on to Dropbox, Azure, FTP, WebDAV and any other protocol suitable for implementation.
Aggressive optimization of the theme files. I have moved the windowing styles into their own CSS file to simplify maintenance. So styles like TQTXWindow, TQTXWindowHeader and so on is now in a separate css file.
The benefit of pushing the windowing styles out of the main theme file, is that AI dont have to chew through all that Base64 encoded image data using for backgrounds and edges. Right now you have to manually add the following tag to the HTML document of your windowing projects (will not be needed later): <link href="window.css" rel="stylesheet">
CSS variables (experimental) I have made one theme file that uses css variables. This means that we have 16 colors defined at the top of the css, and all the styles below it use those variables rather than hardcoded colors. If this works well, we will adopt that as standard. We can also extend the theme unit to include stock font sizes (partially in place) and colors. This ensures greater consistency for application UIs.
Implemented “quick-search” for fast unit searching, the old dialog is still there if you hit CTRL + SHIFT + F or H, but most people will probably enjoy the quick-search. And yes, we will add and polish it until its as good as it can be.
Updated all of ED’s demos! His latest Three.js demos demonstrate live raytracing and hyper-realism which is spectacular!
Fixed the TQTXColorPicker and TQTXColorSelector, both now work as they should
Removed older package that wrapped the Quill RTF editor. This editor was never designed to be resized freely as our widgets do, causing the editor to be all over the place. Please make sure you delete this package (see further down). This has been replaced by our own TQTXRichEditor.
Added icons and glyphs to new widgets and any RTL widgets missing a proper glyph (note: this does not apply to the common widgets that are thin wrappers over stock HTML elements)
Implemented several new codec classes. These are not wrappers but full implementations in QTX itself. Especially useful is the encryption codecs (RTL already contains RC4 codec, base64, utf8 and url codecs).
- Implemented full-duplex RTF codec, capable of parsing raw RTF data and converting it to HTML, or the other way around (full duplex).
- Implemented full-duplex Ansi codec (this is used by the RTF codec)
- Implemented full-duplex blowfish cipher codec
- Implemented full-duplex AES cipher codec
Added support for Firebird databases (NodeJS only) courtesy of Pål Lillejord. The NodeJS namespace now supports SQLite, MariaDB and Firebird. More database drivers will follow.

There are also other highlights in this update, especially two new widgets which really are full sized applications isolated as drag & drop components.

Full drawing program widget

A full drawing program (ms-paint clone with a lot of extras) as a self-contained widget has been added to the RTL (TQTXPaintWidget). Currently it is very humble compared to applications like Paint:Net, but it is an excellent starting point for more elaborate work. In the near future we will add more features to this, including floating windows with the tools, palette and colorwheel, event driven filters (so you can write your own easily) and eventually, layers, shape selection and undo history.

While simple, the painter widget implements the basic functionality. You can use Claude to generate special features for it

As of writing it supports the following “basic” features:

Loading and saving images to TStream, which is uncommon for web components. As well as loading from URL

Fixed palette (currently only 16 colors, will be expanded to a full 256 color palette shortly.
Undo and Redo with standard keyboard shortcut (CTRL + Z, Shift + CTRL + Z for redo)
Pencil (freehand) and line
Rectangle (outline and filled)
Ellipse (outline and filled)
Floodfill and erase
Movable text tool with preview window
Selection and move selection
Variable brush size
Variable opacity (alpha blend)
Proper zoom and ruler-bars

Full RTF text editor widget

Implemented a full RTF text-editor to replace Quill, one that is designed from scratch to be resized and moved without any problems. The new editor turned out far better than Quill ever was.

You can now drag & drop a complete text-editor onto your form, with full RTF support

The following features are supported:

bold, italic, underline, strikethrough and <hr> separator

Variable font sizes (the most common are pre-defined in the dropdown list)
Undo & redo keyboard mapping
Cut, copy and paste keyboard mapping
Bullet and number-lists
Resizable tables
Add / remove columns and rows
Align left, center and right
Foreground and background colors
Clean formatting of selected text, this is a very important feature when pasting in text or HTML that comes with styling or colors
Images, both via code and by pasting from the clipboard
Full RTF loading and saving from TStream via the TQTXRTFCodec. It also supports loading from URL.

Obsolete packages

The installer does not remove old content unless you run the uninstaller first. This is to avoid deleting user-packages. But we suggest you delete the old quill package manually since that is now obsolete. You can find the package files here:

C:\Users\<username>\AppData\Roaming\qtx\packages

While you are there you can also delete any *.bak files to clear up some storage space if you like.

Note: Make sure the IDE is not running, as it will apply a read-lock on packages that are mounted.

Obsolete Templates

The Tabbed Dynamic template is now obsolete. So you should delete the following files (unless you did a clean uninstall first):

File: visual.dynamic.tabs.ini
Folder: visual.dynamic.tabs

These can be found here:

C:\Users\<username>\AppData\Roaming\qtx\templates

Documentation online

We are happy to report that the helpfiles are now available here on our website! This is the same documentation that ships with Quartex Pascal for offline use. We will be expanding the documentation quite heavily to get as much as possible in there for easy access.

Having the documentation online makes life easier. It also helps AI to pick up the dialect

You can access the documentation here, or from the website header at any time.

Demonstrations

Since we are using WordPress (no point re-inventing the wheel), we have opted for IFrame’s, which is a smooth way of showing live demonstrations inline (see below).

Above: A simple WebGL demo showing a cube with six attached boxes to each face flying around a simple phong shaded landscape.

As we move forward, a full demonstration page will be setup for everyone to enjoy!

Quartex Pascal: Easter thoughts

I hope everyone is enjoying their easter! Norway is lovely at the moment with plenty of sun and the sound of birds and nature waking up again.

Between gardening chores and preparing for summer I decided to spend a little time with Claude to spice things up a bit on the NodeJS side – and write down some reflections on where Quartex is going.

Where are we right now?

The roadmap we had setup to span the entire year has (architecturally) more or less, been completed in half that time (a few tickets left like drag & drop database). We have support for datamodules in the bag, we have support for non-visual components (a pre-requisite for data binding) – and we have added a full MCP Server for deep AI integration directly into the IDE.

I feel the IDE now covers the fundamental features you expect from an IDE, but obviously with room for refinement, improvement and expansion.

What I mean with refinement is to take a feature that is already there and simply make it better. A good example is the search and replace dialog. The dialog itself works fine, but a normal ‘quick search’ panel that appears beneath the current editor tab-page is what people are used to from Delphi and Visual Studio. The old dialog will still be there, but only appear when you want it to.

There are several such cases in the IDE, cases where we have the baseline functionality in place – but it could use some specialization and polish. I don’t feel there too many such cases, but enough that you notice them. So we have a few such ‘sub tasks’ that we will be doing.

Going forward

If we look at the IDE as a tree with a several branches, who in turn have child branches of varying complexity -the following off-shoots will see more love as we move forward:

IDE behavior
- Missing details, general polish and refinement
  - Search & Replace (covered above)
  - Welcome tab is too heavy. Get rid of the browser instance and instead have a clean, native, to the point welcome page.
  - Expose more options for toolbars and panels in popup menus, making it easier to tune the IDE as you want it. This can later be expanded so be loaded/saved. I dont feel layout config files are needed unless we allow drag & drop re-orientations of the IDE elements (e.g being able to drag the inspector and place it somewhere else). We can return to this for the Lazarus build later, as Lazarus have some good platform independent solutions for this.
  - Reduce themes to ‘dark’ and ‘light’, no need to ship a myriad of themes nobody actually uses. On Linux and MacOS we have to follow the system themes either way
    - Automatically switch editor colors based on theme. This is only really possible if we settle on a “light or dark” scheme. Right now there is no way to know what colors match any given theme, and having separate color-set-files for each theme is overkill.
  - Do a better job with the default colors for the code-editor. Right now Pascal and JS looks ok, but the other supported filetypes could use some adjustment.
  - implement missing language syntax to our unit interface parser. Right now the parser expects the ‘unit’ syntax rule to be followed. ‘program’ must be added, and it should handle units with no unit or program declarations without throwing an exception.
    - Add support for missing “property xyz: TType read external ‘sym’ write external ‘sym’ [default xyz];”
    - Add support for partial external class. While only useful when wrapping a library compiled with QTX, the parser needs to deal with it
    - Add better support for method declarations in classes (e.g “method xyz: boolean” is the same as “function xyz: boolean”).
- Add support for robo-help extraction, so that ///<symmary> blocks can be extracted from the source-code and exported as a JSON documentation stub, markup or HTML.
  - Add IDE support for JSON documentation stubs. If a package ships with such stubs they should be cached by the IDE (extended help). This is especially useful for AI which will query about classes and methods, and the IDE will be able to answer quickly when there are 1:1 direct match on entity names.
- Make internal logging more consistent, there are still spots where logging only happens when an error occurs, while other parts of the IDE is better at logging circumstantial info that can be useful when hunting for complex issues. We need both, and it must be consistent throughout the entire codebase.
- Export log viewer as a separate application. This helps keep the codebase lean and the log viewer will not be affected by UI locks within the IDE process should they happen.
- The component palette needs to support user-defined categories. Just our own system packages will quickly fill up the list once all the classes that should be TQTXComponents are upgraded, and it will quickly become difficult to maintain. Especially when third party packages start growing.
AI and LLM integration
- Look at ways to add closer integration with local LLM runtimes like LM-Studio, so free models can be used with the IDE in a similar fashion as Claude.
  - Search LAN for LM-Studio instances (if possible) for easier overall use
  - Implement our own console window for LLM use directly in the IDE
- Add support for more local clients. Currently the IDE can emit claude.md into new projects which teaches claude what our MCP server offers and general language guidelines. Other online AI vendors have similar but different init structures
Project support
- Allow the IDE to have multiple projects open at the same time, with a simple way of moving between them
- Add support for project groups (*.qprg file-type needed), which can be very powerful in client / server debugging scenarios. Personally I prefer to open two instances of the IDE.
- Explore PhoneGap and React project types for building native binaries directly from the IDE
- Add support for turning a node server into native apps. This functionality is already there, we just need to expose it in the IDE
- Look at adding Arduino and Micro-controller project types, as well as DB projects with a ready to use setup – and other project types that would simplify getting started
Form design
- Captions for non-visual components
- Redraw composition and region sorting
- Collection pattern: Add support for visual management of TQTXCollection and TQTXCollectionItem’s
- Designer behavior isolation: Right now the behavior of the form-designer is a part of the actual design control and largely triggered by mouse-down, mouse-move and mouse-up handlers. These should be isolated as a separate component. Once isolated this allows us to implement different behaviors separately in a clean way.
- Vertical designer: Right now we have a normal form designer, where controls can be positioned anywhere, or aligned to a particular edge or client region. A top-down designer that operates with horizontal panels stacked one after the other -panels that always are 100% in width, is much more suited for top-down web pages. The same design philosophy is used by GTK on Linux (and QT Creator for that matter) to ensure proportional form layout regardless of scaling size.
- Offscreen WYSIWYG HTML5 live rendering: We need to explore what the QT Framework (which we use for multi platform builds) can deliver. On Windows with a clean offscreen Chromium wrapper it’s relatively simple to do live rendering, but we would need to make it work on Windows, Linux and MacOS for both x64 and ARM. There are some smaller alternatives, like HTMLComponents and Pixie, but again — it needs to be tested first.
RTL and code generation
- Threading
  - DFM to code
  - Unit interface parsing
  - Thread the build process (partially done)
- Ragnarok
  - Implement protocol client codegen. This will expose the client side messages as easy to use methods (e.g fClient.Login( .. ), fClient.DoSomething( .. ) and so on).
  - Implement protocol server codegen. The generated component(s) exposes server side responses as easy to use handlers. Protocols are always client-initiated, so the handshake and any replies are always in response to a client calling. The relationship between request and response messages is defined in the protocol designer.
  - Implement IQTXTransport interface for all supported network objects (http/s, websocket/s, udp, tcp/s etc). This allows an attached ragnarok client or server to ‘peek’ at incoming data, and take ownership of a received message. This way the same TQTXHttpClient or TQTXHttpServer component can be shared by several tasks without colliding. You can drop a TQTXHttpClient component and use it for posting data to a website, and at the same time have a protocol using it as a transport medium without the two tasks colliding.
The entire RTL has plenty of classes that should be lifted up to TQTXComponent, but it will take time since the RTL is large and changes can have unexpected consequences if not properly planned
- NodeJS specific
  - Move all server and client types up to TQTXComponent
  - Cover more modules, both standard and popular NPM modules
  - Generate wrappers for more database types (postgres, firebird etc)
  - Add support for automatically created datamodules for all node.js projects. This requires changes in the build-config and also TQTXApplication and how child objects register.
Documentation
- NodeJS needs to be properly documented, as well as all the default widgets. There is also a lot of ‘how to’ and general understanding that should be added. While a lot of self-evident to developers that already know object pascal, be it they come from Delphi or Lazarus, being able to find reliable info directly in the product is obviously important

The above points are not carved in stone, but rather what I am thinking about at the moment. Some might be pushed forward once we publish our next roadmap, others might be finished before it even becomes a ticket on the map.

AI and the future

Instead of relying solely on Claude, which can get expensive if you are using AI heavily on larger projects – we have actually taken the step of training our own QTX specific LLM model from scratch!

AI is perfect for boilerplate, boring tasks. Like creating new theme files!

This is not the same as just injecting RAG data into an existing vector database (that would be easy). Instead we rented a GPU rack that is building an LLM model specifically for Quartex Pascal. We based the model on the latest Qwen3-Coder series, so the baseline is already highly specialized for programming tasks and fluent in a myriad of languages. When the model comes back it will be quite large (somewhere in the 85 gigabyte range) and needs to be pruned. When the pruning is done we will have a model between 10 and 18 gigabytes (read: normal size).

The benefit of having our own LLM is that it can easily be hosted on our domain and used for automation. But it also means our customers can run our model locally, which further reduces cost compared to Claude or the other commercial solutions. There is also something about being in control of your own AI.

Ai changes everything

Like most developers in their 40s and 50s we are used to IDE’s where we, the human developer, is all that matters. While I still think that is valid – there is no escaping that AI changes how we view and use an IDE.

One of the core design goals for Quartex Pascal was to not add a lot of crazy complex functionality to the IDE which becomes impossible to maintain over time. Instead, I wanted to keep the IDE small, compact and instead keep refining the most commonly used IDE functionality (read: what you expect to find) until that becomes as good as humanly possible.

I think this design philosophy is it’s own reward right now, because had we gone crazy and added a ton of functionality, stuff that would now be replaced by an AI, we would have to maintain a ton of features that no longer makes sense. Of at least is starting to lose it’s importance as LLM evolves.

The benefit of AI is not so much that it takes over. An AI is good at doing the boring parts, the repetitive tasks, the boilerplate stuff – leaving you to focus on what you actually want to create. An AI has by definition no actual creative spark, there is no observer there. And while it’s become very clever at finding solutions to surprisingly complex tasks — you still need an environment where you can implement code or techniques that are new, or novel, or breaks with tradition in some way.

So instead of us adding everything from fancy recordable macros to advanced refactoring functionality which is rapidly becoming extinct — we will instead focus on making the fundamental features shine.

Telling Claude to roll an Android theme.css file takes a few minutes, but it’s ultimately a thing AI can easily automate

For example, spending weeks on a CSS theme designer would be cool ( would actually love that). But I think most people will just explain how the CSS styling works in QTX to the AI, and it will spit out a much better looking new CSS file in a couple of minutes.

The same goes for graphics. Eventually we will no doubt add AI graphics generation to the system, which means the AI will literally be able to spit out not just code, but also the graphics for a website, game or app you are making.