libcvd-members
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libcvd-members] GUI/GVars readline code


From: Georg Klein
Subject: Re: [libcvd-members] GUI/GVars readline code
Date: Tue, 15 Jan 2008 11:36:06 +0000 (GMT)

On Tue, 15 Jan 2008, Gerhard Reitmayr wrote:

I'm fine about the gl part, more interested in the text rendering. I
have been using fltk2 fine, but switched to CVD::glwindow alone to avoid
the dependency on fltk2. now I only have it through gvars3. I'd be happy
to just make CVD::glwindow work on different platforms. If X is ok, then
Unix and OSX already work fine. A windows or Carbon implementation
shouldn't be too hard.

GLX on X on OSX is crippled; to a lesser extent than GLX on Cygwin/X, but it's not good enough, so yes, you'd need a carbon implementation. Re-implementing a GL window class for many OS may seem a nice programming exercise but it's ultimately just re-doing what other people (GLUT, FLTK) have already done; plus it means you have to design yet another input abstraction layer which again, has already been done.

The real annoyance is that on anything other than X, you need some form of window event manager. A nice property of X is that each window can have its own connection to the X server, and therefore the event code for each window is independent. Not so on MacOS, and not so (I believe) on Windows: all windows' events get piped to one central manager. This means you need some sort of messy event dispatching system too. Again, all this has been done (sort of) by other people (FLTK.) This unfortunate fact makes FLTK's irritating single-global-instance trait somewhat forgiveable.

If some simple, independent text rendering could be had (or someone can
design a nice line font, mine are dreadful :). I looked at various nice
gl wrappers of freetype but it just adds lots of dependencies...

a pure gl GUI implementation could be added to gvars3 (replacing the
current toolkit bindings) or just used by myself...

I think a GL window with associated user interface should be its own project, which may depend on GVars, but should not be part of it. It's too big a task IMO.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]