[mcclim-devel] xxxx

[Jack Unrue]

Greetings,

I've had a few days now to sort of stumble around in my initial
attempts at implementing a new backend[1]. The existing backend
code and the spec help a lot, so the stumbling is just me getting familiar
with a new codebase which for me is always a challenge. I think various
concepts are starting to sink in. Apologies in advance for naive statements
in the following and feel free to correct my understanding :-)

I've got the general idea that a backend implements a class hierarchy
with the responsibility of tying backend-specific constructs (represented
by mirrors) to the system-agnostic representation (panes, sheets,
and gadgets). The resulting McCLIM object hierarchy needs to shadow
the logical structure in the native windowing system (e.g., window
parent/child relationships). In McCLIM, one implements specializations
of make-pane-1 and realize-mirror to accomplish that. Correct?

Looking at the existing backends, it appears to my inexperienced eye
that I have considerable latitude in establishing the mapping. That includes
making use of various classes, functions, etc whose symbols are in the
climi package, as needed. It's nice that there are various sanity checks
in place that help catch mistakes. But essentially there are no prohibitions
beyond those sanity checks and expected behavior as described by the
spec? I haven't yet found any list of "do's and don'ts",  e.g. on McCLiki, but
hopefully folks will provide review feedback to that effect.

At the moment, my event dispatching solution consists of implementing
get-next-event for my port, returning the appropriate event type based
on my mapping between Windows messages and CLIM events. I'm not sure
yet whether I can implement the timeout feature. Anyway, I'm not otherwise
touching any of the event queue-related stuff that I see in McCLIM proper,
and I'm assuming for the time being that this backend will not enable
multi-processing -- if and when SBCL/Win32 gets multi-threading then
I'll have to revisit this.

I haven't yet delved into mediums and designs, as I'm still trying to get
basic window, menu, and gadget construction working correctly. But
graphics support is obviously on the near horizon.

I'm looking forward to making code available as soon as I'm not
completely embarrassed by it :-)

-- 
Jack Unrue

[1] for those that haven't heard, I'm working on a Win32 backend via
Graphic-Forms, which is my CL library for Windows GUIs.