Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!iuvax!cica!ctrsol!ginosko!uunet!mcvax!guido From: guido@cwi.nl (Guido van Rossum) Newsgroups: comp.windows.x Subject: Re: Using Xlib instead of toolkits Message-ID: <8288@boring.cwi.nl> Date: 25 Jul 89 11:46:35 GMT References: <3437@ncsuvx.ncsu.edu. <1210014@hpfcmgw.HP.COM. <15326@watdragon.waterloo.edu> <2281@auspex.auspex.com> Sender: news@cwi.nl Reply-To: guido@cwi.nl (Guido van Rossum) Organization: The Royal Society for Prevention of Cruelty to Amoebae Lines: 29 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."