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 writes:
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?
Not quite. As an implementor of backends, you have a choice between which sheets should be mirrored: pretty much every sheet, only the top-level sheet, or any solution in between. For the X11 backend, as many sheets as possible are mirrored, but there are backends (OpenGL?) that do not have a hierarchy of windows, and for such backends, CLIM does implements the parent-child relationship itself.
-
Jack Unrue -
Robert Strandh