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

[Gerhard Reitmayr]

Georg Klein wrote:
> 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.
> 

In general, I agree and thats why I have used fltk2 sofar. However,
CVD::glwindow provides exactly that. I'm not limited by the reduced GLX
on OSX functionality, but that's only because I am not using the modern
GL features.

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

yes and no. windows needs a generic call to retrieve events but can
automatically dispatch them then to a callback per window. so that would
be the singleton manager that you need to call per iteration. not sure
about Carbon on OSX.

but even in the X mode you have to call your windows to allow them to
communicate with the X server. so now you have to keep track of all of
them somehow and regularly call them. (all of this assuming single
threaded programming).

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

sure, that was just a suggestion, I am keeping it currently in a
separate library depending on GVars. but if you think about your own
screen gl interface, it has already buttons, toggles, sliders and a
simple hierarchical menu structure, not less than the current GVars GUI
bindings...

in any case, its interesting to hear what others are doing :)

I think, somehow I am more fed up with making dependencies work (on
different platforms, new versions of systems) than with putting in a few
days work and get something that I understand well. However, I have
started to look at Qt4 again (currently in Python) which seems to work
better at the cross platform stuff.

> 
> _______________________________________________
> libcvd-members mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/libcvd-members


-- 
Gerhard Reitmayr
MIL, Engineering Department, Cambridge University
http://www.eng.cam.ac.uk/~gr281/
tel: +44 1223 765150