Robert Strandh wrote:

Hi,

patrice.lespagnol at obs-nancay.fr writes:

...

I'am interessed in using the OpenGL backend of McCLIM : what is its state currently ? What would be a good start point to work on it ?

The state is that it hasn't been worked on for a number of years, and that it is unclear how much of it is working.

Your best bet would be to send email to moore at bricoworks.com or simply to experiment with it to find out what is working and what isn't.

After seeing some conversations about the OpenGL backend at #lisp and finally here, I'd really like to get some people together to work on it.

The current OpenGL backend is based on CLX' OpenGL bindings. Currently there's far more activity at the cl-opengl project, which is more lispy and cross-platform, ie. not bound to X. McCLIM should use that instead.

I really like Inertia (http://www.mike-austin.com/inertia/), which is a OpenGL based User Interface written in different languages, like Ruby and Dylan. The code is small, simple, very clean, really good comprehensible. Porting the snippets should work easily.

Reading http://kantz.com/jason/clim-primer/application-frames.htm: " Frame Managers -------------- * control the realization of the look and feel of a frame * interpret the specification of the application frame in the context of the available window system facilities * take care of attaching the pane hierarchy of an application frame to an appropriate place in a window hierarchy

Kinds of Frame Managers ----------------------- * desktop manager or window manager o allows a user to manipulate the frames of other applications o is usually a non-Lisp application o acts as a mediator between the Lisp application and the host desktop manager o application acting as frame managers o allow frames of other applications to be displayed within the host application "

I'd like to use the OpenGl backend both in two "modes":

a.) for each frame: ask the window manager to get a window (via glut) and draw the frames contents (text, buttons, ... ) inside the window. That's how the CLX and gtkairo backend work.

b.) ask the window manager for *one* window (via glut) and for each frame draw a "window" (in the glut window) it's contents. That's what inertia does.

Does a CLIM frame-manager support these modes or is the spec just based on the concept a.)? If both are possible: What mode is more favorable? Or work on both and have a common code base?

For fonts ZPB-TTF (http://www.xach.com/lisp/zpb-ttf/) should be used, it's native lisp and works very well.

For graphics there are two possibilities:

a.) software-based: Vecto (http://www.xach.com/lisp/vecto/) is great for vector graphics. Don't know what to use for bitmaps.

b.) hardware-accelerated: as we're already working with hardware-accelerated 3D graphics, we could also use hw-accelerated 2D graphics. There's the unfortunately unknown OpenVG (http://www.khronos.org/openvg/) specification, available from Khronos, the consortium that also makes OpenGL. There are some open-source implementation, the best being currently ShivaVG (http://ivanleben.blogspot.com/2007/07/shivavg-open-source-ansi-c-openvg.html) written in C and based on OpenGL. It's simple, fast and has at least most of the functionality needed. I've written a cl-opengl-like wrapper library cl-openvg, which works very well.

I really like CLIM and it's features, but both gtkairo and CLX are not cross-platform and not appealing. With OpenGl both is possible. If we make McCLIM pretty and cross-platform, it'll attract more developers and users

So, anyone interested in this possible project, please comment and give feedback. Any help is appreciated.

Thanks!

kind regards, Bastian