Re:Xt is not the problem (Score 1)

By dispensing with Xt, Qt and GTK+ can provide small lightweight components which are relatively easy to port. The big problem with this approach is the fact that in throwing out Xt, you also dispense with any attempt to provide a proper object level component model. This has very serious side effects, particulary with respect to scalability of the language. Compare and contrast with Java. In this language, I can write a GUI builder which can walk up to any bean, and dynamically query the attributes of the object, present a resource panel to the user, and from thence, generate code. I can do the same thing to a slightly lesser extent with an Xt widget based component: I can query the widget class, extract resource table data, and again present a proper resource panel for the instance of the widget class concerned. All just by dynamically poking into the widget class: all the information I need is right there in the object itself. I cannot do this for Qt or GTK+. Although Qt provides the QtWidget, this object is a specimen skeleton only: the resource tables for this component are NULL. There is no way to dynamically query a Qt/GTK+ component and deduce sufficient from the object pointer: the essential property of introspection is missing from the design. This has two consequences. Firstly, I cannot write a GUI builder (this happens to be what I do for a living) that will dynamically load third party components for the languages without providing a complete object description to the builder. But no equivalent of UIL/WML for these environments exist. Secondly, I cannot write a component which can be dynamically slotted into someones GUI builder, because there is no hook which will allow my component to talk. The component vendor and the GUI builder each needs the other, but in the absence of a component model, there is nothing which will allow them to talk. This means that anyone writing a GUI builder for the languages has to statically build in such knowledge as is required to present to the user from the start: you have to hard code what the object fails to deliver. There are other issues I have with these environments, namely to do with support for internationalization. there simply is no equivalently powered Qt/GTK+ mechanism for the XmFontList/XmRenderTable/XmString combination. The world does not all speak English: in fact, most of it doesnt. In this respect, Qt and GTK+ simply arent good enough. This has two consequences: firstly, there are upgrade issues associated with trying to keep the latest release of the base software in step with whoever provides the GUI builder. Secondly, in the absence of the professional GUI builder/third party component market, which we have already decided cannot be provided, you have no option but to either write all your code by hand, or pass control of your application to some private piece of hobbyware which masquerades as a support environment. This stuff just isnt going to scale into the professional large scale international market. You can write small to medium scale projects with it (dont get me wrong, I personally think Qt to be a very well written language indeed) but you are not going to get into the space shuttle test program domain.