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

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

On Wednesday 05 November 2008, Paolo Donadeo wrote:
> > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > the relevant limitations of Qt4 with quite easily.
>
> Jon, did you ever used Qt in a big C++ or Python project? Qt is the
> best GUI framework out there, GTK is a ridiculous toy in comparison,
> and it took ages to reach this level of "completeness". Frankly, I
> think you are heavily undervaluing the task of building a *decent* GUI
> from scratch.

I wholeheartedly agree.

Jon's valid point is that some concepts in Qt's core are unnecessarily
complicated due to the fact that there is no higher-level concept of
a display list or scene description.

This necessitates things which in would be hacks given display lists
/ scene descriptions. Case in point:

A QTextEditor or QPlainTextEditor is an editor widget which works on
a QTextDocument. A QTextDocument has an associated implementation of an
QAbstractTextDocumentLayout. The latter has methods such as anchorAt(QPoint),
blockBoundingRect(QTextBlock) and hitTest(QPoint). Those methods
are only necessary since once a document is laid out by the layout
engine, any links between the rendered representation and 
the document are hidden by the Q...TextDocumentLayout. What 
QTextDocumentLayout does is to simply send a bunch of primitives to
the QPainter which actually renders them on some device, but this
is done without using any sort of a list.

Even if a display list (QPicture passes for it) was used, it's a closed-up
class that, while holding a display list, provides no trivial access for it.
You can of course play() a QPicture on your own a QPaintDevice that talks to
your own QPaintEngine, but there is no functionality in place to attach
your own data to elements of such a display list, unless you resort
of course to another layer of hacks. No such metadata functionality
exists for QPainterPath (which is closer to a real display list) either.

And neither QPainterPath nor QPicture are really hierarchical. About the only
way to think of a hierarchy for Qt's drawing system is at the level of 
QPainter, which provides save() / restore() functionality for its state.
All of this structure is implemented by the QPainter(), so as soon as
a QPainter() paints on a QPaintDevice(), what little hierarchy was there
is irretrieveably lost.

So Qt would benefit from having real, hierarchical display lists, which could
then be expanded to include 3D functionality. Trolls may well be working
on this (I hope they do!), but it's no small feat to have it done in a way
which "just works" like most of Qt does.

Qt is not bug free, and a colleague of mine is hard at work bugging the trolls
with a new (mostly event-related) bug every week (not kidding you). But he
really runs into some corner/less-than-well-documented cases due to what
he's trying to do. Yet that's still way better than dealing with a toolkit
that's fairly new (MPC) or something that gives you 10% of the functionality
you need.

Cheers, Kuba