[mcclim-devel] Status?

[Duncan Rose]

On Wednesday, November 2, 2005, at 01:53  am, C Y wrote:

> List has been a tad quiet lately - is anything going on at the moment?
> I've seen a few comments here and there about R-trees but the list has
> been alarmingly quiet.  So I'll make some noise :-).
>
> (BTY, nevermind my spec license question - presumably since it's being
> distributed with McCLIM it's at least LGPL compatible, which is good
> enough.)
>
> 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.

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.

>   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. 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.

>   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...

> I'm sort of curious if McCLIM+lambdagtk could make a reasonably modern
> looking CLIM, and GTK provides high level functionality which would be
> nice to use, but I'm a bit at sea as to how to approch this from an
> McCLIM backend perspective.  My instinct is to go top down, tying high
> level functionality in the spec to high level toolkit functionality and
> working down to lower level objects, but obviously the clx backend only
> interfaces to the outside world through the clx communication bridge,
> and has to implement everything else it needs on top of that.  Beagle
> is presumably working at a somewhat higher level since it's getting
> some Aqua look and feel working but I haven't really understood how
> that's being handled yet.

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.

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).

>   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....

-Duncan


>
> Cheers,
> CY
>
>
> 		
> __________________________________
> Start your day with Yahoo! - Make it your home page!
> http://www.yahoo.com/r/hs
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>