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? 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). 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?
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. 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.
Cheers, CY
__________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
C Y smustudent1@yahoo.com writes:
List has been a tad quiet lately - is anything going on at the moment?
These days work on McCLIM tends to be concentrated in occasional bursts, but it does happen. To keep up to date with the latest and greatest, you may for example subscribe to the mcclim-cvs mailing list, or check my blog (see signature).
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? The Beagle backend, as near as I can tell, loads clx
I'm afraid nothing similar exists. But there is a little known experimental backend, not included in McCLIM's source tree, you may not be aware of. It's the Cairo backend by Gilbert Baumann:
http://bauhh.dyndns.org:8000/mcclim/cairo/
Here you can find source code and screen shots. This material may provide additional insight on how a McCLIM backend can be implemented.
Paolo
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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
--- 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
-
C Y -
Duncan Rose -
Paolo Amoroso