From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, DNS_FROM_SECURITYSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 055F9BBAF for ; Wed, 5 Nov 2008 16:44:48 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8BAJVOEUlDWxLCbmdsb2JhbACBd5IiPq0XhmKELoNT X-IronPort-AV: E=Sophos;i="4.33,551,1220220000"; d="scan'208";a="31152350" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail4-smtp-sop.national.inria.fr with ESMTP; 05 Nov 2008 16:44:35 +0100 Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16]) by server1.bertec.net (Postfix) with ESMTP id 799CD105735 for ; Wed, 5 Nov 2008 10:44:26 -0500 (EST) From: Kuba Ober To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] What does Jane Street use/want for an IDE? What about you? Date: Wed, 5 Nov 2008 10:44:24 -0500 User-Agent: KMail/1.9.10 References: <200810200919.41561.ober.14@osu.edu> <200811042336.48392.jon@ffconsultancy.com> <4b5157c30811050039s659575ack8b6e9a9026e67835@mail.gmail.com> In-Reply-To: <4b5157c30811050039s659575ack8b6e9a9026e67835@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811051044.25761.ober.14@osu.edu> X-Spam: no; 0.00; ocaml:01 gtk:01 higher-level:01 renders:01 trivial:01 trolls:01 bug:01 trolls:01 bug:01 cheers:01 paints:98 feat:98 hacks:01 hacks:01 wrote:01 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