Tuesday, February 21, 2006

UI Layout Management, redux

I got a little ahead of myself with the previous entry. Having gotten my first (simple) layout manager working the traditional way, at this point, I think that geometry management in a UI toolkit might be too narrow an application for a generalized constraint solving framework. One of the ideas I might salvage from that last entry is the notion of providing an extended set of layout management primitives with a abstraction over it. That might happen after I’ve done some refactoring. As it stands now, I’ve got a workable interface between layout managers, the containers that rely on layout, and widgets organized via the layouts.

Tuesday, February 14, 2006

UI Layout Management

I’m planning a series of blog entries that discuss the design and implementation of Graphic-Forms layout managers via a constraint-solving engine. In a nutshell, GUI layout management is an abstraction for UI composition whose purpose is to handle the messy details of organizing screen display based on attributes of UI elements plus policies selected by the application programmer. On top of the library usability aspect, layout management is a key enabler for I18n. It seems to me that constraint solving is a powerful but also natural foundation on which to build a layout engine. Check out this tutorial for some background reading on geometric constraint solving.

While I am not claiming that this combination is a novel idea, I do feel confident that it makes sense, given the kind of job that a layout manager needs to accomplish. And as an algorithmic solution, it leverages one of the fundamental strengths of Lisp-based languages.

It’s important to keep the target audience in mind when designing features. The core layout manager can be built with as much generality as desired, such that it understands a broad range of possible layout strategies, and that is definitely a goal. But for usability’s sake, Graphic-Forms should provide pre-defined layout schemes that are each focused on a particular behavior that the developer needs to accomplish. So while the underlying engine may provide enough flexibility to define arbitrary layout schemes, the canned schemes are built on top of the general mechanism and these are what the average developer deals with. But there is an added benefit – advanced developers can use the same mechanism to extend the toolkit’s layout functionality without needing to reinvent the core primitives.

One other preliminary comment: this is an area of the toolkit that is sensitive to performance issues, because

  • real-world application windows and dialogs are often stuffed to the gills with components (usability be damned)

  • the end user will definitely notice repainting performance problems

In an ideal world, the creation/resizing/reorganization of windows and dialogs is near instantaneous as far as the end user can perceive. The reality of course is that overhead is an inescapable factor. Everyone has seen at least one GUI application which exhibited jerkiness or obnoxious flashing in painting as windows are moved and resized. Visual artifacts like that leave a bad impression. Therefore, one of Graphic-Forms’ goals is to strike a balance between power/generality in implementation vs. snappy responsiveness on the screen. I anticipate having to make some hard choices.

For next time, I’m planning an overview of design issues and maybe some discussion of layout manager features available in other UI libraries.

Sunday, February 5, 2006

Graphic-Forms, a new UI toolkit

I’ve been making progress on a Windows-only toolkit for CL, called Graphic-Forms, which I had intended to use for my own projects. But this weekend, I decide to take the plunge and get a project set up at common-lisp.net (still waiting on the reply to my project creation request, though). I hope this code ends up being useful for other people besides me.