[mcclim-devel] Status?

[C Y]

--- Duncan Rose <duncan at 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