Note: This website is archived. For up-to-date information about D projects and development, please visit

Library Strategy

When I design something in UniD, these are my priorities:

To use UniD, a developer should NEVER have to...

  1. Conform to a particular design-pattern
  2. Write repetitive, obscure, or ugly code
  3. Make special cases for various operating systems
  4. Have to read the entire reference manual just to get started

Design-Pattern Freedom

UniD is not a religion, and I am not a design-pattern dictator

There are many ways to write something as complex as an application with a graphical user interface. When creating a library that acts as a mediator to both the operating system and graphics rendering library, it seems tempting to dictate how an application must be structured, which in effect specializes the library to a particular use-case or personal preference. UniD aims to be as general as possible, in both abstraction and imposed structure.

Beautiful Code Clarity

Code should read easy, but more so it shouldn't read like a broken record sounds

The D programming language gives us a way to express ourselves in source code more elegantly, and more accurately. It is my goal to take advantage of this in designing the way that a developer interacts with UniD. Additionally, the code follows the naming conventions set forth in Tango and the D Style Guide.

Blissful Platform Ignorance

Platform specifics are not your problem, they are mine, let's keep it that way

I was once an SDL user, and in my very first project I had already made several special cases for various operating systems just to implement what seemed to be functionality well within the scope of SDL, but they were so focused on supporting Amiga that they let the lowest common denominator set the bar for the rest. Whenever a platform doesn't support a feature which is important to application development and particular to the operating system, it will be faked. An example of this is the default window position and size on X11 vs. Windows or Mac. X11 is not a window manager, so it doesn't keep track of window positions and sizes, and thus doesn't have a default. In this special case, UniD makes the decision to default to 640x480 @ 100x100, ensuring the application behaves predictably on all platforms, without bypassing the useful functionality that may not be available everywhere.

Delightful Development Easiness

When possible, things should be so intuitive the developer could guess how to do it, and be right

Not only should code read well, but it should be easy to write. This is very true for D and Tango, and it's important to uphold that principal in UniD. Vectors are a good example of making otherwise lengthy (and always more bug-prone) code shrink down to a line or two without loosing any descriptive information. Another example is how certain metaphors like begin and end are used throughout the library, helping to keep a consistent and logical flow to an application.