dlangui gives the D language a cross platform widget toolkit

An Android style widget model ported into D

dlangui is a GUI library for the D programming language, and the design lineage is stated in the README: it is mostly inspired by the Android UI API, covering layouts, styles and a two phase layout, and it is a port with major refactoring of the OpenGL based GUI library from the Cool Reader project, which was written in C++. That lineage explains the vocabulary. There are themes, styles, state substyles and resources, and they behave the way an Android developer expects. A theme is a container of styles and can be loaded from an XML theme resource file, styles are addressed by string ID inside a theme, and styles can be nested so that a missing attribute falls back to a base style. State substyles change a widget's appearance dynamically based on its state. The default theme resembles the one in MS Visual Studio 2013, and resources can be embedded in the executable or loaded from an external resource directory at runtime.

The single thread rule decides how your application must be shaped

The most consequential line in the feature list is a constraint, not a capability: the library is not thread safe and all UI operations should be performed in a single thread. That is a real architectural constraint on whoever adopts it, and it rules out the usual pattern of a worker pool feeding results straight into widgets. Any background work has to hand its results back to the UI thread through some marshalling mechanism, and the README does not describe one, so that part is on you. This is not an oversight in a toy library, a similar single thread rule is common in retained mode toolkits too, but it does mean a dlangui application looks structurally different from a program that can update widgets from any goroutine or thread.

Backends, OpenGL acceleration and the fallback path

Rendering is layered so that hardware acceleration is optional rather than required. The library supports hardware acceleration using OpenGL when built with the USE_OPENGL version, and it falls back to the pure Win32 API, SDL or X11 backends when OpenGL is not available, for example when the OpenGL dynamic library cannot be loaded. The dependency list in the README shows how the backends are chosen: binbc-opengl for OpenGL support, bindbc-sdl with SDL2 for cross platform work, an X11 binding when SDL2 is not used, bindbc-freetype for FreeType support under Linux and optionally under Windows, and arsd-official for image reading and XML parsing. Windows uses SDL2 or the Win32 API as backend and Win32 API for font rendering, with FreeType as an option. Linux uses SDL2 as backend, FreeType for fonts, and FontConfig to enumerate available fonts. The README also lists a simple 3D engine that allows 3D scenes to be embedded within the GUI, and the examples directory includes bezier, d3d and dragon directories that exercise that side.

Building the example app with DUB on Windows and Linux

The documented path to a running program is DUB, the D package manager, and the example1 application is the reference demo. On Windows, the repository is cloned with submodules because the dependencies carry their own bindings.

git clone --recursive https://github.com/buggins/dlangui.git
cd dlangui/examples/example1
dub run --build=release

On Linux the backend needs SDL2 development files installed.

sudo apt-get install libsdl2-dev

The runtime then loads the shared libraries for freetype, opengl and fontconfig, which the README says are required as binary packages. The Linux build command is the same DUB invocation with a package selector.

cd examples/example1
dub run dlangui:example1

Building requires DMD frontend 2.100.2 or newer, which is an old floor by current standards and tells you this code targets an older toolchain generation. The README also warns that a failed build is usually a dependency version problem rather than a source problem, and gives a two step recovery: force a dependency upgrade, then force the build.

DUB dependency drift is the most likely build failure

The README devotes a full section to a problem that would otherwise eat an afternoon. Its advice is that if the build of your app failed due to dlangui or its dependencies, you probably have not upgraded dependencies.

dub upgrade --force-remove
dub build --force

Removing dub.json.selections is mentioned as another thing that sometimes helps. The reason this is worth writing about is that dlangui is a library consumed through DUB, and the library's own dependencies move underneath you. The DUB package resolution picks versions, and a version bump in a transitive binding can break your build without any change in dlangui itself. The cost of using this library therefore includes the habit of forcing a clean upgrade whenever something stops compiling. The repository layout, with src/ holding the library, examples/ holding about fourteen separate demo programs, and views/ plus android/ directories, is consistent with a project that is developed by iterating on many small demos rather than a single application.

macOS is claimed but explicitly not guaranteed

The README is unusually direct about the weakest platform. It says DlangUI theoretically supports MacOS, then adds that the author has no way of testing whether it actually works, and that the support is not guaranteed. That sentence should decide the question for anyone shipping a macOS build. There is a derelictcocoatest-monod-osx example directory in the repository, but a directory is not a test matrix. The same section says other platform support may be added easily, which is an optimistic reading of a port that needs a backend, a font path and a build configuration. The practical conclusion is that the platform coverage in the README, Win32, OSX, Linux and Android, overstates the verified coverage by at least one platform.

Resources, internationalization and the licence

The resource model uses reference counting, and the README is explicit that widgets must always be destroyed implicitly for proper freeing, which is a habit D programmers do not always have from other D libraries where garbage collection handles it. The FontManager gives access to fonts, images are .png or .jpg, and a filename ending in .9.png is autodetected as a nine-patch image using the Android drawables convention. StateDrawables read from .xml files can describe a list of other drawables chosen by widget state, and files from Android themes can be used directly. Internationalization is listed among the main features. The library is released under the Boost Software License 1.0, with LICENSE.txt in the repository root and a separate licence file for the default theme icons. The related DlangIDE project, a D IDE built on this library, is described as able to open DUB based projects and edit, build and run them, with DCD integration for go to definition and autocompletion.

Editorial conclusion

dlangui suits a D developer who needs a desktop or Android user interface without leaving the language, and it suits anyone who wants the Android widget and theme model outside Android. It is the wrong choice if you need macOS support you can rely on, because the README states that support is not guaranteed and that the author has no way of testing it, and the wrong choice for a multi threaded application, because the library is explicitly not thread safe and all UI operations belong on one thread. Before committing to it, build the examples/example1 demo with dub run --build=release on your target platform, install libsdl2-dev on Linux, and run dub upgrade --force-remove if the build fails on dependency versions. The last push was on 2026-10-10, while the latest tagged release is v0.10.8 from 2024-07-13.

Frequently asked questions

Official sources

1. buggins/dlangui on GitHub
2. Issues
3. License: BSL-1.0
4. README
5. Releases