tbray@watsol.waterloo.edu (Tim Bray) (07/24/89)
You should be using a toolkit in any case. Xlib is not the right level of abstraction for building entire serious applications, unless you are a masochist, or a toolkit implementer. Or want to do any of a number of things that are difficult or impossible with Xtk; or want to make a lean and mean application. Or think X is probably the way to go, but aren't yet convinced which toolkit/widget set is going to be the right one to use, and can't wait for the dust to settle. We have just finished doing a serious text display and manipulation application in Xlib, and while we found the interface hard to *learn*, we thought it was OK to *use*. There were definitely some things we needed to do with which toolkits would have caused all sorts of trouble. Obviously, we layered on some standard packaging for getting a window displayed, abstracting input events, etc. Anybody else with similar experience? So in using Xlib, are we like the dumb people who insist on using assembler instead of C, or like the smart people who insist on using C instead of Ada? Tim Bray, New Oxford English Dictionary Project, U of Waterloo, Ontario
guy@auspex.auspex.com (Guy Harris) (07/25/89)
> You should be using a toolkit in any case. Xlib is not the right level > of abstraction for building entire serious applications, unless you are a > masochist, or a toolkit implementer. > ... >Obviously, we layered on some standard packaging for getting a window >displayed, abstracting input events, etc. Sounds like you implemented a toolkit, which puts you into category 2) of the categories listed above.
guido@cwi.nl (Guido van Rossum) (07/25/89)
In article <2281@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>Obviously, we layered on some standard packaging for getting a window >>displayed, abstracting input events, etc. > >Sounds like you implemented a toolkit, which puts you into category 2) >of the categories listed above. Indeed. In many cases it's worth writing your own lean and mean toolkit instead of relying on the intrinsics (Xt) and a specific widget set. (Your own toolkit doesn't need to rely on Xt.) This will buy you vendor-independence (true, Xt is available everywhere, but most widget sets aren't) and performance: Xt and most widget sets provide almost infinite flexibility, but at considerable cost -- carefully chosen restrictions to a particular problem domain can make your own toolkit a lot faster (especially to start up) and smaller (hence faster again). Maybe Xt and a widget set could be seen as rapid prototyping tools -- they have some of the desirable properties for such tools, such as extreme flexibility. Unfortunately, one essential thing is missing: debugging an Xt program can be a nightmare, and lint nor the compiler catch type errors in widget argument lists, for instance. Also, I wouldn't say that writing a new widget is easy... Unless you take the source for an existing one and modify it to suit your purposes. -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or guido%cwi.nl@uunet.uu.net "Repo man has all night, every night."