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/

4 comments:

Anonymous said...

Hi jack,

Besides being focused on the windows platform, can you briefly explain what other differences are there between graphics form and CAPI or wxCL? (CAPI apps look very primitive)

Also, is graphical form just a layer of wrapper functions for the win32 api? For instance, like http://www.lisphacker.com/blog/display/some-sbclwin32-hacking

What other features are missing to consider it a good platform to develop sophisticated windows app? (Like what you can do with dotnet windows form).

Thanks!

Jack Unrue said...

Hi, thanks for your questions.

CAPI is mature and established, whereas Graphic-Forms is not yet. I would eventually like to have broader coverage of common controls and dialogs than I think CAPI manages right now, especially looking forward to Vista. CAPI has support for ActiveX controls, which is a topic that I have yet to really consider. At the end of the day, it may be tough for me to beat CAPI (or the Allegro GUI stuff), but then that stuff isn't available on the free Lisps.

wxCL is in-progress, and it may eventually cover as much or more functionality than my library will, thanks to wxWidgets. I'm not a big fan of the wxWidgets class hierarchy, however. And I'm also not too happy with the concept of wrapping a C++-based class hierarchy with a Lisp one. I should point out that I contributed some code to wxCL last year; Surendra Singhi is great to work with, I just decided that wrapping wxWidgets was not a long-term goal I wanted to work towards.

There is still a lot of work to do in Graphic-Forms before I would feel comfortable positioning it as realistic competition, especially relative to CAPI. It's a major goal of mine to make Graphic-Forms work well on the free Lisps, so porting to new implementations is a priority (plus I think code quality improves as you port from one compiler to the next, see a previous blog entry about that :-)

Graphic-Forms is not just a library of wrapper functions. It's designed to leverage platform-specific features, but provide a nice Lisp-y interface. To that end, I already have a language for defining menu hierarchies, a plugin system for integrating image-processing libraries, an architecture for layout management, and I plan more higher-level functionality along those lines. Graphic-Forms does use a low-level binding for the Windows API, implemented via CFFI. But I provide some extensibility at that level, particularly in that you can add new methods to specialize on particular WM_*** messages that Graphic-Forms process for its own needs. Anyway, the bottomline is that it's a lot more than running swig on windows.h.

I would like to build a higher-level library on top of Graphic-Forms, sort of a cross between an application framework (think of how JFace relates to SWT) and a real Lisp-y framework with a built-in listener for rapid prototyping.

Just to focus on one feature that I know wxCL does not have yet (and I don't believe CAPI has either) is the facility for integrating external image manipulation libraries that I mentioned above. I have a chapter in the reference manual that starts to explain this plugin system, but the basic idea is to let folks use whatever library (supporting whatever image formats) they want, even multiple such libraries at the same time. And on the application side, have this be a configuration issue rather than write code specific to each such library.

I have not thought about integration with .NET. If that's something you're interested in, you're probably going to want to look at RDNZL or something similar. One thing I would say, though, is that Win32 and GDI will still be around for a while, even considering all the noise MS makes about Vista and .NET. So strategically, I'm pretty comfortable using those APIs.

Sorry for the long-winded reply, but I hope I've answered your questions.

Michael Jung said...

Hello,

with yr help on c.l.l. I managed compiling sbcl-0.9.15 on win32. But graphic-forms just do nothing, no window is shown at all. I tried hard on both WinXP/Win2000, but as I'm just a newbie to Lisp I do not really know where to search for the reason.

Any idea ? Thanks in adavance !

Jack Unrue said...

michael, can you give me any more info? Anything happening in your console window, like the debugger getting triggered? Does SBCL just go right back to the normal prompt?

Also, can you send info to graphic-forms-devel? It will probably be easier to discuss this problem over e-mail.

Thanks!