--- Duncan Rose <duncan@robotcat.demon.co.uk> wrote:
On Wednesday, November 2, 2005, at 01:53 am, C Y wrote:
I have a question about Backends, or rather what it takes to make one. Is there any kind of template somewhere in the spec, a "Provide all of these graphical abilities and IO routines and you have a valid Backend" kind of document?
There's no such document as far as I am aware. But basically the back end is responsible for optionally implementing any methods that specialize on frame manager, frame, medium and mirror + the lower level event handling.
OK. So whatever isn't handled by calls to external routines is implemented in the Lisp backend in terms of lower level routines?
When I wrote Beagle I copied the methods from the CLX back end and tried to write Cocoa equivalents. The last time I made any changes to Beagle I was really hitting a wall I think because of this approach though (Cocoa /= CLX) so ymmv following this path.
I was sort of hoping to "start clean" but that might be an exercise in folly.
The Beagle backend, as near as I can tell, loads clx and then provides Cocoa parts in a gradual shift from clx to Cocoa, but it's not clear to me how a developer knows what to implement and what it needs. The clx backend, presumably the most complete one, is a bit intimidating. The keyboard IO stuff is a bit scary (I suppose that really is a hard topic but only the graphical toolkit people ever run into it).
There shouldn't be any CLX dependency if you're running Beagle; the back ends are totally divorced.
OK.
The developer generally finds out what's missing when he (I would say s/he but I think there aren't any females working on McCLIM currently ;-) tries to execute some application that dies horribly.
Ah, the fun way :-).
Also, if one wants to provide higher level interfacing, for example create an McCLIM menu gadget and tie that directly to GTK's menu API instead of lower level McCLIM gadgets, how would one go about that?
You want to read the chapters on windowing (6-9?) and the ones on panes and gadgets (23, 24?). Chapter numbers in this mail are non authoritative, but the contents page in the spec. should make them obvious...
Sounds good.
CLIM is specified in terms of 'logical windowing ops' (for want of a better term); the back-ends provide methods that define these in terms of actual window toolkit calls. Beagle doesn't act at a higher level than CLX, at least not as far as CLIM is concerned. The Beagle code is actually higher level than the CLX code I think, but that's because the Cocoa API is defined in OO terms and at a higher level of abstraction than the CLX API.
Ah, OK. (Looks like SLIME+xref is going to be a useful tool here...)
I'm not convinced that a more abstract API is better however in this case; it seems Cocoa and CLIM want to do be responsible for many of the same things, and forcing one or the other to work differently to the respective design is an annoyance (this seems to be particularly bad with respect to event handling and drawing text).
Hmm. Knowing Apple, I take it CLIM is more general than Cocoa wants to allow? I remember you mentioning that, I'll have to go back and reread those emails.
Can somebody recommend a "McCLIM backends for dummies" guide? Some place in the spec perhaps? I'll keep digging but I though maybe someone could put me out of my misery and point me in the best direction to head.
The code is the best documentation....
I was afraid of that... oh, well. Time to kick back and do some recreation spec reading... Thanks much! CY __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com