In the lack of something more creative, QuindiGUI is the way I named a graphic interface engine assay written in C++ I made during my free hours.
If you read the page about Pixel Pocketknife with attention, you may have noticed that I like to polish bits and to have the domain over the application details.
In Pixel Pocketknife implementation there is a hierarchy of visual components classes that encapsule objects offered by Windows.
There is also a visual components position and size management engine (layout manager).
In the program source code, I create visual components indicating what are the dependencies of each of them and what position and size rules they have to follow.
These features allow me to create complete and complex windows with aesthetics, without the need to explicitly declare literal sizes and distances, because it is the engine that makes the calculations.
But I wanted more!
This graphic interface engine of PixPoc is totally dependant of Windows 32 bits.
I wanted the same visual components concept, but with more domain of the events they trigger and are subject to, and with more control over their drawing on screen.
So I began the QuindiGUI assay.
The idea was to isolate the operating system dependency and make it as restricted as possible.
QuindiGUI asks Windows only for "raw" windows (without title bar, without frame, without anything) and basic inputs such as mouse and keyboard inputs.
The windows drawing, as well as the implementation of all visual components that go inside them, is QuindiGUI responsibility.
In other words, of the visual components offered by the application, only the windows have a corresponding Windows object associated; all the others are "virtual".
Even the window behaviour, like its resizing by means of the mouse, is implemented by QuindiGUI.
Realize that this approach would allow me to port QuindiGUI to other operating system with relative ease: assuming that I had a compatible C++ compiler available, only the OS dependant portion would have to be rewritten.