For a file manager (btw, I've found standard Haskell file access functionality very limited, but GHC's should be a lot more practical), you'll want 2d representations, orthogonal projections, and well-antialiased bitmapped fonts, so your requirements differ from mine - HOpenGL is a wide playing field!-) But GLUT's bitmapped fonts might be an acceptable starting point (just), and are just as easy to use as its stroked fonts.

I really want to use one of the binding to freetype. My goal is to write a file manager (and then a panel, and a desktop manager) which is fast to develop, and looks nice. I mean: to have the feel of all 2d f.m., but to have 3d enhancements, like transparency, animations and so on; using haskell could allow user-supplied code to be compiled at startup and to be safe (I could limit user code to a monad with few operations, which can't do IO for example). So, I need opengl to render everything and maybe my project will become some form of "cool widget set" itself. For now, it's just an idea, nothing more. And I think that any amatorial plan needs to have functionalities "on demand": I start writing a file manager, and implement everything related, avoiding to bother of anything else. I'm not sure I will succeed, yes, but I want to try.

Here are some relevant links

http://homepages.paradise.net.nz/henryj/code/index.html#FTGL http://oglft.sourceforge.net/

I've seen that oglft needs qt (which is not GPL on all platforms) to be able to use unicode. It's a trouble. And FTGL does not mention unicode, I 'm going to download it, surely.

Bindings to one of the latter two would be really nice, but they also seem to add new dependencies (on the libraries themselves, and on the FreeType software they build on..).

I don't think it's a problem. Reuse adds dependencies, but simplifies coding.

...

Is this a good moment, or should I wait for FFI?

If we believe the marketing hype, ghc-5.04.1 will have what it takes, and the FFI spec is stable (they say..).

Yes, but (as far as I know) ghc's FFI is not implemented in other haskell systems (or am I wrong?). I mean, is there a standardized way to call foreign code? Am I wrong? Thanks for your explanations of the GLUT font system... it's better now ;) I didn't understand that rendering a character implicitly uses "GLtranslate" so I didn't "pushMatrix" and "popMatrix"... it's really better now :) Vincenzo

Nick Name wrote,

...

...

Is this a good moment, or should I wait for FFI?

If we believe the marketing hype, ghc-5.04.1 will have what it takes, and the FFI spec is stable (they say..).

Yes, but (as far as I know) ghc's FFI is not implemented in other haskell systems (or am I wrong?). I mean, is there a standardized way to call foreign code? Am I wrong?

GHC 5.04 implements the proposed standard FFI. Hugs is currently being brought in line by Alastair Reid and nhc98 has it on its todo list. This is as close to a standard as you'll get at the moment. For anything OpenGL related, I would recommend to take exactly the same route as Sven has done. Consistency is good! Cheers, Manuel

On Sun, 21 Jul 2002 20:10:05 +0200 Sven Panne wrote:

The just released GHC 5.04 has spec-conforming FFI support, as does the CVS version of Hugs. NHC98 almost has it IIRC, but I'm not sure about this. Simply ask Malcolm about this.

...

and the FFI spec is stable (they say..).

Apart from some esoteric features and occasional clarifications the spec is indeed very stable.

Good. BTW I don't think it's a good idea to write bindings for a widget set, because they're written in C, and could take bugs and segfaults. Font renderer are far more complicated and I am surely not able to write them, and besides they require high efficiency. For widget sets, I think it's better to develop a UI model totally independent from the graphics library , for example copying that of Fudgets, or of IHaskell, and then implement it in HOpenGL. Maybe the implementation should be parametric in respect to the functions used to draw (we could have "themes" which can change the behavior of the library). It's just my humble opinion Vincenzo

It takes a lot of effort to develop a good library.

First of all, from now on, I want to point out that I am not so good at english, so I'll be often unclear. I am really sorry for this. And, I've not been unclear, just excessive in what I said. I am not criticizing anything, I've used GLUI in the past and found it fast and bugfree, for example. What I had in mind, and didn't say, is that it *might be* that reimplementing GLUI in haskell, following its design principles, could take less time than one could imagine, and bring a type-safe implementation. This is not true for QT, for example, which is full of so many functionalities no one can think of re-implementing it. Anyway I am not willing to reimplement GLUI, so it was not a critique, just my opinion (and I am just a computer science student, undergraduated, so my opinion doesn't matter so much :). Of course, It absolutely wasn't a critique of FFI in Haskell. It's not only useful but also necessary, for example for OpenGL or OpenAL, without counting that, even if GTK is NOT bugfree, there are many people that want or *need* to program for gtk, and could be interested in haskell. And, it's a programmer's choice what to consider part of the bare machine (and write an FFI binding) and what to consider "the software" and prefer to write it in haskell. What I am looking forward is to take an "haskell like" UI design and implement it, but parametrized in respect to the actions to be taken. So it could be reasonable to implement my design by myself, a binding for GLUI, and to instantiate my more abstract design using calls to GLUI (whose binding would surely result in a very "imperative" feeling). And, on the other side, to implement some "cool" widget in haskell+opengl, using the visual enhancements that opengl can give, and to instantiate the abstract UI with this widget set. In fact I am using console stubs by now, because I'm focusing on what structure is better for a file manager. An haskell program written for the abstract UI could then use one or another. It's just an experiment, I want to keep things well separated.

when the machine is thrashing, when handling exceptions, when the thread allocation limit is reached, etc. (I single Haskell out here because by making more things implicit than many other languages, Haskell makes it harder to reason about and deal with failure.)

It's a problem, but it's what we have to study. We cannot think that nothing serious can be done in Haskell because memory exhaustion would crash the program. Yes, I still have to read the articles around about imprecise exceptions ...

For this reason, I think it makes a lot more sense to incorporate existing libraries into Haskell and then build cleaner layers on top.

Yes, in fact, I am going to split my UI to allow this, but I want to play with opengl and have a funny toy-like visually-astonishing opengl widget set. Nothing more than that. And, besides, I know I won't succeed, but I have to try. If someone else will make a binding for GLUI I will ensure that my "clean" design (I am almost sure I will copy fudgets or ih, just let me some time to study both) will be implementable with GLUI. I need to clarify that I spoke too fast, and made a mistake. What I want to do in my spare time is a binding to a font library because *I* consider it more important. But this doesn't mean this isn't important, I agree. Vincenzo Ciancia

Anyone can suggest what FFI I should eventually use?

There's only one ffi. But if you want an ffi _frontend_, I'd point out that GreenCard is portable, stable, provides a clean Haskell-style interface (e.g., result codes are readily translated into Haskell exceptions), and generates portable code. Of course, I'm biased since I'm one of the authors. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/

Oh yes, I meant frontend, just I wanted to know if ffi is accepted and stable or "nearly finished" (and so it could change) as written on

http://www.haskell.org/libraries/

I foresee some small changes based on the experience creating a third implementation.

but yes I trust greencard... should the ffi change greencard will not, right?

Right. I can imagine tweaking the internals to generate threadsafe code (not previously a problem since compilers didn't generate threaded code) and the ffi distinguishes three levels of 'safety' whereas greencard only distinguishes two so there'll be a change there too. [btw The other ffi frontends are worth looking at too but I don't know them as well.] -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/

In the last weeks I've been re-structuring FunGEn completely (that's why it is taking so long for version 0.2 to be released). I read Mark's CGL (Clean Game Library) thesis and found a lot of useful information and ideas. The main objective is to make FunGEn a engine that deals much more with worlds/leves/objects SPECIFICATIONS rather than programming all the stuff in a IMPERATIVE way (actually, its first version had a little bit of it).

BTW, I've got no FunGEn feedback at all (apart from Sven's notes just after releasing)... :(

Sorry, I booked it as "great, but not down my alley" - didn't reckon that a game engine would build on a kind of scene graph as well, even if in 2d. How do you deal with animating the scene graph? The combination of declarative descriptions of scene graphs, animation, and reactivity were just what Fran was designed for, but it has traditionally posed some problems in efficient implementation. I think those have their source in unfortunate aspects of Fran's design which I'm currently trying to overcome. Guess I'll have to take a closer look at your stuff soon, but from your FunGEn 0.1 example at http://www.cin.ufpe.br/~haskell/fungen/example.html it seems you've got separate data structures describing the game resources, the collections of game objects and the possible inputs (the later bundled with their callbacks). The timing functionality looks like a thin wrapper around the two GLUT timing callbacks? The game object actions are then written as monadic actions with easy access to other objects' properties. If that summary is not too far off, FunGEn 0.1 is still a mixture of declarative and imperative descriptions. Will that change with FunGEn 0.2? Game hackers might welcome the familiar style (as long as noone tells them they'd be using monads;-). Cheers, Claus

On Sat, 20 Jul 2002 13:43:02 -0300 "Andre W B Furtado" wrote:

SPECIFICATIONS rather than programming all the stuff in a IMPERATIVE way (actually, its first version had a little bit of it).

Yes, I noticed that the pong example was a little "imperative" ;)

BTW, I've got no FunGEn feedback at all (apart from Sven's notes just after releasing)... :(

I am looking forward to experiment with it, but if you are rewriting I need to wait. Why don't you get a sourceforge account so you can get a cvs server? Vincenzo