Werkema.com: Software: SpaceMonger 2.1: Wink

What is Wink?

Wink^TM is a software-development framework that we've been working on for the better part of four years. Its first public use will be by SpaceMonger v2.1, but its capabilities are not limited to just SpaceMonger. Wink is a full-fledged portable general-purpose software-development framework for C++ with over 180,000 lines of very carefully written code in it. It's a complete replacement for the C/C++ standard libraries, as well as providing a portable user-interface framework, graphics facilities, regular expression handling, XML parsing, HTML rendering, and hundreds of other capabilities that you'd normally only get by assembling dozens of other libraries consisting of millions of lines of code.

Wink is broken into the following major subsystems:

Base: Provides basic portability support for C++, including portable data types and operating system kernel-level functions and classes.

Core: Provides all the kernel- and language-level facilities that Base doesn't, including all the stuff that you'd normally expect from the C/C++ "standard" libraries. Base is designed to be as small as possible, interacting with the real operating-system kernel as little as possible to keep applications and the framework more portable. Core provides everything else, including strings, "cooked" files, malloc(), date/time routines, debugging tools, collection templates, and generic algorithms.

Dynamic: Provides templates, classes, and macros that allow more flexible inter-class communication in C++, similar to what other object-oriented languages are used to. Provides closures in the form of Action objects for better callbacks. Provides string-to-data decoding/encoding as well.

Geometry: Provides classes and functions for coordinate mathematics, including points, rectangles, and colors. Right now, this is limited to integer manipulations, but that's only because the floating-point vector/matrix code is #ifed out for want of testing.

Lax: The dynamic lexical analyzer. Lax is designed to be a drop-in replacement for most regular-expression parsing code, from simple comparisons all the way up to what compiler-compilers like lex can do. Lax compiles expressions to a DFA and processes it, just like all the good regex libraries do.

XML: Provides event-based restartable *ML parsing. The XML parser returns tokens as it parses, and is fully restartable (in case you temporarily run out of input, such as over a slow network). It can be configured to full XML strictness, HTML weakness, or anything in between. Internally, it uses a huge state machine for parsing, so it's very, very fast.

Image: Provides facilities for image-handling. Handles images from 1 bit to 24 bit color, with or without a palette. Can load and save images in many formats. Can manipulate images with standard transforms, like flipping and rotating, and with standard filters, like brightness/contrast and gamma and sharpness and smoothing, histograms, quantization, dithering, and more. Provides facilities for basic drawing on the images as well: draw a line, draw a rectangle, draw text, bitblit, cropping, expanding, alpha blitting, etc.

Gfx: Provides the notions of a "Drawable" and a "Context". Provides many abstract drawing operations, font-caching, region-management, and knows how to use a Context to draw on a Drawable. Drawable and Context are abstract constructs that are concretely implemented by anything that can be drawn on, such as the host GUI and Image objects.

UI: Provides the basic notions of "Window System" and "Window" in very abstract form, including all the facilities for manipulating them. The UI subsystem has no direct support for any physical window system: it merely provides an abstraction-and-translation layer between the sophisticated Widget layer and the super-simple implementation layer (Win32GUI, XGUI, MacGUI, ImageGUI, etc.). It is sufficiently abstract that Window objects can be even be reparented between window systems on the fly, and Window objects may not even necessarily be tied to physical system-provided windows: they might be just paint on the screen, but only the application will know for sure; the Windows themselves can't tell the difference.

HTML: Uses the XML subsystem to decode and render HTML, not into a Window, but using whatever Context you provide. Currently correctly handles and renders standard "quirky" HTML, but doesn't understand CSS or JavaScript (probably will in future versions). Does not include any networking code, and never will (that's left to other subsystems).

Config: Uses the XML subsystem to store application-configuration data into external XML files. From the application's perspective, this works a lot like the Windows Registry, but its files are portable to other operating systems and they're easier to back up.

Widgets: Implements all the widgets in a typical user-interface. Provides things like Buttons, Menus, ScrollBars, and dozens upon dozens more, all the way up to sophisticated widgets like pop-up FileDialogs and drop-down ColorPickers. Also provides a few other UI facilities, like i18n databases for foreign-language support.

Template: This subsystem knows how to use XML descriptions of user-interfaces to construct actual widgets. This provides an easy way to build good-looking user-interfaces that can rearrange themselves when the user resizes them or when the text size or font size changes.

Win32 GUI: Provides minimal hooks for interacting with Win32-based operating systems. In reality, this provides only the Win32CoreSystem and Win32CoreContext objects, letting Gfx, UI, and Widgets do all of the hard work of displaying the user interface.

That's a lot of stuff, particularly for only 180,000 lines of code. Only Base and Win32 GUI know how to talk to the underlying operating system (although in the current version, Base and Core are included in the same library). Everything else is portable.

Interestingly, you'll notice that there's no mention of treemaps in that list: that's because Wink has nothing whatsoever to do with treemaps. SpaceMonger implements the treemaps itself: Wink is a general-purpose portable application framework, and SpaceMonger just happens to be the first real use of it. There are no plans to move the treemap renderer or disk scanner into Wink.

Much more stuff is planned before the first public release of Wink. Several things in the current code need to be cleaned up (not that it's bad code: we just don't like the way it works). The old ASCII code needs to go and be fully replaced by Unicode. Some new capabilities need to be added: the "Image GUI" subsystem (doing windowing on an Image) is missing, for example, as are "Network" (TCP/IP support), "Sound" (audio I/O), "RawInput" (raw mouse/keyboard/joystick device input), "RawDisplay" (raw pixel-drawing on an output display), "Print" (printer Drawables), and "GL" (hooks for using OpenGL on a Window Drawable or a RawDisplay Drawable).

In short, sorry, you don't get to see Wink except indirectly though applications that use it; it's ours right now, and it will probably stay that way for a long time. But we do hope that it'll someday meet our impossible standards for publicly-released source code, because using Wink is a lot nicer than any other framework out there that we've ever used for any language, and you'd love it.

Oh, you're probably wondering where the name "Wink" came from. Well, so am I. When I first started working on it, I needed a name to start working under, so I tossed in a few names that nobody seemed to be using and "Wink" stuck because it was the shortest. I think I may have been thinking "WINdowing Kit" at the time, but frankly, your guess is as good as mine. I drew the logo a couple of months into the project and the name has stuck ever since.