Wednesday, August 30, 2006

Mr. Interesting-Problems-To-Solve

I had to laugh a while back when I read through one of the now semi-recent threads on comp.lang.lisp, wherein a certain old-timer boasted about how many of us ought to send him our resumes. Although he had his hands full with interesting problems to solve, he allowed as to there being possibly a month or two of boring code to be dealt with afterwards; and we knuckle-draggers who spend most of our time slogging through the muck might be able to handle that (pending credentials review, of course). OK, he didn't write anything about "knuckle-draggers," that part was my invention.

Getting the boring code done -- the stuff about to drive you bonkers because it's so boring -- is a thankless job, but you'll hear about it when you actually get users and they find out you've skimped on certain details. The boring code stops some people from getting their projects past a certain, how shall I say it, critical juncture. Everybody prefers the interesting problems (the 20%), but some folks can't grind out the rest of the project (the 80%), and they move on to greener pastures. I don't think Mr. Interesting-Problems-To-Solve is one of those folks; I'll bet his work is good and thorough. But I laughed because I've seen that attitude for real.

Now where was I? Ah yes, list box notification messages. Oh goody.

Tuesday, August 22, 2006

Graphic-Forms version 0.5.0 released

Release 0.5.0 of Graphic-Forms, a Common Lisp library for Windows GUI
programming, is now available. This is an alpha release, meaning that
the feature set and API have not yet stabilized.

Here is what's new in this release:

. SBCL is now supported (specifically version 0.9.15). Graphic-Forms
includes a small patch provided to the SBCL community by
Alastair Bridgewater to enable the stdcall calling convention for
alien callbacks. Please see src/external-libraries/sbcl-callback-patch

. Implemented a plugin mechanism for integrating graphics libraries. This
means that ImageMagick is now optional -- if your application can get
by with just BMP and ICO formats, then the default plugin (which has no
external dependencies) may be used. This feature also allows applications
to integrate other graphics libraries of their choice.

. In addition to ImageMagick now being optional, external library
dependencies have been further simplified. Several small libraries
are now directly bundled with the Graphic-Forms. Cells is no longer
used in the library proper nor in the demos (but may return at a
later point).

. Implemented a class called icon-bundle which may be populated with
multiple images and then used to set icon data for window frames.
This includes the concept of there being 'large' and 'small' icon
sizes.

. Simplified the argument lists for the event-*** generic functions.
Provided gfw:obtain-event-time as a substitute for passing a time
argument to every function (for which the vast majority of methods
had no use).

. Defined the following new generic functions:

* event-session GF so applications can participate in the
WM_QUERYENDSESSION / WM_ENDSESSION protocol.

* event-activate and event-deactivate GFs so applications can respond
to window activation state changes.

* GFs for querying undo and redo state. Implemented corresponding
methods for edit controls.

* GFs for configuring auto-scrolling and scrollbar visibility. Implemented
corresponding methods for edit controls.

* GFs representing text clipboard data convenience functionality.
Implemented corresponding methods for edit controls.

. Made other miscellaneous improvements to flesh out edit control
support.

. Implemented the standard color chooser dialog and associated
convenience macro 'with-color-dialog'.

. Added the macro 'with-graphics-context' as a convenience for code that
needs to instantiate a context outside of event-paint.

. Heavily revised internal layout manager code in preparation for
supporting more sophisticated layouts. A new class called layout-managed
has been created to serve as a mix-in when defining objects (not
necessarily only windows) that have children to be sized and positioned.

. Implemented a new demo program called textedit which is essentially
a Notepad clone. Its purpose is to show off the multi-line edit
control and the standard Find/Replace dialog.

. Upgraded to the latest lisp-unit and changed test loading code so that
unit-tests are no longer compiled.

. Wrote more documentation and reorganized existing content a bit.
Added discussion of certain naming convention choices.

. Made a variety of bug fixes.

The README.txt file in the release zip file also has additional important
information about this release.

Download the release zip file here:
http://prdownloads.sourceforge.net/graphic-forms/graphic-forms-0.5.0.zip?download

The project website is:
http://common-lisp.net/project/graphic-forms/

Saturday, August 19, 2006

porting code is good!

A long time ago, I used to work at a company called XVT Software, whose main product during that time was a C-language-based user interface portability toolkit. (Yes, we had other products, but the C toolkits were the bread-and-butter). For those of us on the development team, the mantra was 'port early, port often.' We had to deal with lots and lots of environments, and as anyone in the biz back then knows, even within (or especially within!) the Unix-like family tree, the differences between vendor implementations were huge. So you saved yourself a lot of trouble by following our mantra.

Even though as a complete Lisp newbie I knew there were differences between CL implementations, I have only recently started to understand at a deep level how much our old mantra from XVT applies to the CL world. I now have code running well on LispWorks, CLISP, and SBCL. And what I've discovered is that code porting, rather than being a negative, is actually very healthy. In my experience, it has been a process of fine-tuning and improvement, as each new compiler points out bad habits, opportunities for cleanup, etc. In fact, I would go so far as to recommend folks with single-vendor codebases to make some effort at porting to at least one other implementation -- no matter how good your current compiler is (or how good you *think* it is), there will almost always be new/useful tidbits that another compiler will point out. If you try it, I think you'll be glad that you did.

Friday, August 18, 2006

Just testing Writely integration with my blog. Move along, nothing to see here.

Sunday, August 13, 2006

graphics library plugin mechanism

I've recently implemented a neat abstraction in Graphic-Forms. For quite a while now, it has been possible to load image files from disk so that they may be displayed. Until recently, I required the use of ImageMagick to handle the file loading task. It's a very nice library, and I have a small binding implemented for the MagickCore API which is the low-level C-based API. But it's also heavyweight -- your process ends up loading quite a large number of DLLs due to interdependencies in their code, and what's possibly worse is that you pretty much have to do a 'real' install because their code expects certain registry entries and directory structures to exist.

What I've done is to create a simple plugin mechanism, the key aspect of which is implementation of a bit of code in each plugin to translate from library-specific representation of image formats to the Graphic-Forms IMAGE-DATA class. The latter is then what the main library code consumes for image creation and attribute querying. When an image file is to be loaded, each registered plugin is given a chance and the first to succeed wins.

Based on that mechanism, I've now implemented an ImageMagick plugin that you can use if you need to handle more formats besides BMP and ICO. Or if those two formats are all you need, you can load the 'default' plugin which has Lisp code that understands those two formats directly. You can implement additional plugins in application code if you want to use some other graphics library; I plan to document how to do this in the next release.

By the way, another benefit of this strategy is that you can write pixel processing code in terms of IMAGE-DATA or in terms of the external library of your choice, and then create IMAGE instances using IMAGE-DATA as input to display the result.

Thursday, August 10, 2006

SBCL port

Just a quick update. Among the various things I'm working on for the next release, I've now got a significant part of Graphic-Forms up and running on SBCL/Win32. Woot!