Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!EXPO.LCS.MIT.EDU!rws From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler) Newsgroups: comp.windows.news Subject: Re: event-driven applications Message-ID: <9001101529.AA02771@expire.lcs.mit.edu> Date: 11 Jan 90 01:18:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 115 I take this to be roughly an argument that a multi-threaded OS is needed to support separate thread event dispatch using the Xt or other similiar toolkit model. It's possible to use application-level threads and get somewhere. The main problem with such an approach is system calls blocking all threads; you have to understand application specifics to know how bad of a problem this is (but it's definitely a problem for some applications). What current OSes support this? Mach, Sprite, Symbolics, TI Explorer, Cedar, V(?), probably others. It seems like there is a relative abundance of application-level threads packages for C, although few of them are widely/easily available I guess. Processes are now fairly common in product Lisp systems. Several people have put threads into C++. Is this something that users can rely on anytime in the future? If OSF has its way, Mach may be widespread eventually. :-) There is a POSIX committee working hard on a standard Threads definition, indications are that they are making considerable progress. Clearly the model is designed for simple applications, not those that have vastly complex interfaces. I've seen a number of X products that are quite sophisticated. (I don't know about "vastly complex", we don't encourage those. :-) The model breaks with more complex interfaces and applications that do real work rather than heavy UI and light functionality. The model breaks when there is significant "computation" in parallel with user interaction, if that computation cannot easily be decomposed into Xt's notion of "work procs". I agree completely. But, as I have argued in the (distant) past, user interaction in sophisticated applications will very likely require interaction with the "back end" data of the application, and can't always be "downloaded" into a window server and run autonomously; multiple threads will be needed in the client as well. I remember Mark Callow of SGI at a SIGGRAPH panel a couple years ago admitting this turned out to be essentially the case for several applications they had been building. It is *not* good that Xt isn't adequate for all applications, simply because it is being asserted as a _standard_ on which all toolkits are to be based. You have the emphasis in the wrong place. It is *a* standard; the X Consortium does not view it as the only possible standard. I strongly disagree that one should build the universal toolkit (whatever that is) or be damned; I'd much rather take the 80% rule (and be damned :-). One of the common citations is that Macs/PCs have a wealth of useful applications, yet they are based on essentially the same model. By locking all users into a deficient standard prior to the marketplace understanding the variables in the game, one has effectivily crippled further progress in this area. When I count the number of new toolkits *still* being designed in the X environment (whether Xt based or not), I find it hard to agree that progress is being crippled. On the other hand, I've talked to a fair number of real end-users (e.g. people from federal agencies), and their almost universal cry is "give us something yesterday, I don't care what it is, I trust you that it's good enough for what I need to build right now". Standardization is an attempt to satisfy those kinds of needs, hopefully without stiffling innovation. It's a tricky road to walk. I have yet to meet someone that could understand programming Xt in a single sitting; and there are pretty amazed reactions when people get into understanding it. Anecdotal evidence is hard to compare. I have an undergraduate (a freshman as I recall) with no prior experience in windowing or graphics, just a little bit of C programming. We gave him the task of rewriting bitmap(1) to be a toolkit client, using the Athena Widgets. He read the documentation, asked very few questions, and poof, he's got a reasonably good application up and running (certainly much better than the current bitmap), including having written his own widget. Those here that have attempted to use it have been pretty smart, and it was no cakewalk to understand it for them. I agree it is difficult. I think a large part of it may be the documentation (e.g. separating out cleanly what widget users need vs. what widget writers need). I hope the Asente/Swick book nearing completion will help. And widget set documentation is getting better, as people learn how to present the information better. But making this a standard that all have to understand and suffer with simply limits the commercial viablity of Unix/X in the face of OS/2 and PM. Gee, I've read the PM documentation, and I can't say it's any better. If we want X to win then why is the door shut to creativity beyond the Xt class based model? Who in the world ever said it was shut? There is a wealth of creativity going on. Look around; attend the X Conference. :-) But, there's no consensus on any of it yet, that would enable standardization. I'm not really sure what your complaint is. You seem to want the world's best toolkit, which doesn't exist and probably won't in our lifetime, yet complain that people have agreed to a common definition of something that does in fact enable a reasonable range of applications to be built. Since there are multiple ways to skin this cat, and you state that Xt isn't the final solution, why is it a standard? Because multiple vendors rely on the Xt foundation, and desire to have a common, vendor-neutral definition and evolution of that layer. If the same were true of some other interface, the X Consortium would consider standardization of it.