Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober <ober.14@osu.edu>]

> > Have you ran recent Qt demos distributed with Qt? I'd say they look
> > pretty cool in my book.
>
> They would not have impressed me a decade ago, let alone today. Many of
> them don't even work on either of my Debian machines.

I have one question regarding OpenGL: maybe it's just me, but isn't core,
or "historical" core OpenGL blissfully unaware of simple concepts such as a
path, a brush, stroking a path etc? This was long time ago, but I recall that
drawing a circle using OpenGL implies that you (or some middleman library) has
to discretize the circle into triangles, and then render that.

Again, correct me if I'm wrong, but typical OpenGL-based UI rendering
will do good old antialiased software 2D rendering on OpenGL textures,
and the composite some simple 3D models with those textures applied.
[Or it may, at a cost of generating *way more* triangles, use shader
programs.]

That way you can get goodies like shadows of text rendered in a window
with transparent background, but it's really awkward to do directly in
OpenGL. These days I imagine this "2D" rendering can be done using
shader programs, but that excludes a lot of commonplace hardware
outright, and hits some implementation bugs hard (just look around at
various game forums). And I really don't quite love the idea of
generating a bazillion triangles for the 3D hardware to then
shade: I wish 3D hardware could work with splines of some sort (does it?).

AFAIK/IIRC, as soon as you wish to move to a higher level scene
description, where basic primitives such as paths live in 3D, you have
to implement a whole lot on top of OpenGL, and there are no real
standards as to how to do it. If anything, Cocoa and MPF (?) may be
examples of how to go about it, but that's a long shot of where
we'd all like to be.

I would like nothing better than to work with hierarchical interactive
display representation, where simple things remain simple: say you have
a letter shown in your text editor widget, and you want to know where
the said letter is located. With a scene description graph, you can
extract that information -- the way Qt does it so far either requires the
text layouter to provide you with relevant API, or you have to plug yourself
between the layouter and the paint engine and literally listen for where the
glyphs get painted. The scene description would be easier to use, of
course. If the scene description has links into the underlying text document,
as it well should, then it gets even easier.

So, please understand that I'm not oblivious to benefits of thinking in
higher levels of abstraction, but I'm also practical and know that Qt
provides me with a whole big lot of cross-platform functionality that
simply doesn't exist anywhere else in one coherent platform.

Oh, and it's not like scene graphs and whatnot cannot be nicely done
in C++ ;) (ducks and runs).

Cheers, Kuba