The PT Toolkit

Targeting software from the same code base to run across many different platforms and devices is not easy, and with certain software stacks it has made it very accessible but there are costs. One size does not always fit all.

I’ve started working on a new toolkit, PT, short for Platform Toolkit, which will allow developers to use commonly used GUI API’s on popular operating systems to build applications. You can find it here:

I aim to support Linux with GTK, Microsoft Windows, and possibly Apple macOS through Cocoa. I am still unsure what kind of low-level native library to use on Android, but as I don’t have a MacBook, iOS will not be supported. In any case, it will be something which has reasonable feature parity with all other platforms.

But why write another toolkit? The reason is due to dissatisfaction with the size and complexity of existing libraries belonging to Qt. It’s hard to justify using Qt in a small utility, which has an installation size of 20 megabytes. You can reduce your program’s size by linking your binary against custom built static libraries for Qt, but this process is long, and the build process is complex despite the adoption of CMake and other scripts to help simplify the process.

Programs that use the Win32 API’s are only a few megabytes, and it should be possible for programs on other platforms to have a similar size. I hope my toolkit will help developers to achieve this.

Ironically, with web browser runtime libraries having the notoriety of being hundreds of megabytes, there is one called Sciter which makes for a reasonably sized application, but is, unfortunately, closed source.

Another similar runtime could be built, but web browsers add a lot of overhead including the JavaScript interpreter, CSS, HTML parsers, the layout and the rendering engine, which may ultimately calling the same underlying API’s that a native GUI application would call anyway.

On the subject of interfaces, one of my aims is too maintain a core set of interfaces which will only differ in their implementation, but I’ll also expose native types, such as the window handle, if the developer needs it for platform specific functionality.

If you have any suggestions or feedbacks about the future of PT, please leave submit an issue or feature request on GitHub:

Leave a Reply

Your email address will not be published.