Tuesday, September 25, 2012

vector 1.0 beta

The vector project is a commercial open source offering for Java2D via DigiVac.

Sorting out the problem of doing 2D really well for graphical user interfaces has been one among many interests of mine since 1996. It's now 2012, so that's (2012-1996) = oy = sixteen years. In the nineties it was called "Syntelos Viz". Along the way there have been many returns to the subject, including my rewrite of wtkx, an almost unrelated restructuring of pisces-graphics, and then digging into 3D with fv3.

Most recently at DigiVac, we've been building telemetry and telecommand GUIs for vacuum instrumentation. This is getting fairly involved, now, with demand for the internetworking of vacuum instrumentation. There's many ways to do TM/TC via internet, and we're doing quite a few of them.

Doing GUI on Java is surprisingly limited. The platform options are messy. Get too far into a project and you end up wishing you had the time to do stuff like this, which is not fun but an example of trying to make some APIs do something that was not on the menu. Most GUI framework options are either not quite for interaction, or not really nice. Not like pixel programming, not like GL, but some kind of API for its own sake.

The vector package is a new incarnation of work done over the past couple years in support of the DigiVac GUIs. Starting again from an empty directory, with plenty of experience immediate in mind, consolidating lessons learned into the principles of a framework for applications.

vector assumes nothing, writes no pixels that have not been explicitly asked for. This simple premise is a powerful beginning for a graphics programming framework. Likewise, it denies access to no pixels that have not been explicitly rejected.

In this spirit, the principal Component is an interface that can be implemented by any class. A Container is defined using external, common static utility functions making it equally reproducible.

In this moment, the limit of advancement is at the frontiers of text editing. Images and paths remain to be done, but are easy enough to do in the application layer. Text editing is fairly challenging. First there's bi-directional text, mixing right-to-left and left-to-right languages. And then there's attributed text, adding color and font.

Very often there is an API chasm between the GUI application programmer and facilities for attributed text editing. In vector an approach has formed that lifts this facility into the open.

This demo shows the TextLayout class in action, displaying attributed text, and one medium sized step away from editing attributed text.

Basic bi-directional text works, as for Hebrew, but the cursive languages like Arabic and Persian remain to have their ligatures connected.

The TextLayout class demonstrates the vector approach to full featured text. It is a container populated by Text objects as are employed for buttons and labels and text line editors.

The Button adds an interactive, first class Border which is identically applied to Containers and other Components.

I think I've finally solved this problem. It's really been bugging me.

In my experience the final piece of the puzzle was breaking the GUI versus Content layout problem. I'm sure this is taught in school, if you took that class with that prof: it becomes pretty trivial once you identify the problem. But then, applying all the lessons is the trick, anyway, isn't it?

A GUI wants to do layout in a top-down way. Given a window frame, the pieces are assembled in a programmatic composition of relative coordinates. The composition is edited programmatically to add and remove the components in the scene.

Some things in the GUI behave like Content, which wants to do layout in a bottom-up way. A shape like an ellipse or rectangle has a size defined by the author, and the composition can be scaled to fit into each other and the window frame.

Maintaining both ideas in a programming framework produces a cyclic dependence within the component of a composition. If the framework is not clear enough in resolving this issue, it will be more complicated than it needs to be. A component able to scale and size itself programmatically is certainly a ready source of confusion for maintainer and developer, alike. What is the bounding box of the component? Scaled to fit within a parent container within the window frame? Or simply the rectangular circumference of the content of the component?

The vector package answers this question with clarity and no loss of flexibility or generality.

It defines programmatic principles for layout in terms of indempotent visual state transitions that accommodate both layout strategies: top-down and bottom-up. It defines an interface for components that are capable of either one. And it permits both scaling and translation at the component level. The tabgrid demo shows a strictly cartesian component hierarchy distributing mouse input events among these various coordinate spaces.

I have high hopes for this project: no doubt that it's as great as I think it is.

No comments: