Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!sun!frisbee!jcb From: jcb@frisbee.Sun.COM (Jim Becker) Newsgroups: comp.windows.news Subject: Re: event-driven applications Message-ID: <130009@sun.Eng.Sun.COM> Date: 9 Jan 90 00:28:36 GMT References: <9001031356.AA01664@expire.lcs.mit.edu> Sender: news@sun.Eng.Sun.COM Lines: 100 rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: Like, say you want a program to go away for a while and do some work. Under X you lose the UI... and you can't even put up an "I'm busy" sign because it won't get displayed until you return to the event loop. Another over-generalization that seems typical for this list. I will try not to make the same mistake. These comments are focused on _your_ comments regarding Xt. "X" is a whole lotta things these days. To claim that all instances of X applications are single-threaded and strictly event-driven, in the canonical manner of Xt, is rather silly. There are multiple researchers out there working with X on the client side in a multi-threaded environment; there are even one or two products that work this way. Whether a multi-threaded client environment is better or worse than a single-threaded client with multi-threaded server is rather debateable, I'd say. 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. What current OSes support this? Is this something that users can rely on anytime in the future? Will all OSes to which X is ported allow this model? Given the basic design of the X event model there are a number of problems that arise when creating more complex applications than those more closely interface driven. These are starting to arise now that developers are venturing into _real application land_. The design of Xt was a concious one, for its portability across a wide range of systems. Clearly the model isn't adequate for all applications; that's good, it was an engineering solution. ~~~~~~~~~~~ Clearly the model is designed for simple applications, not those that have vastly complex interfaces. The model breaks with more complex interfaces and applications that do real work rather than heavy UI and light functionality. 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. If the initial foundation is inadequate then it should not be deemed the standard on which all solutions are based. 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. 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. Those here that have attempted to use it have been pretty smart, and it was no cakewalk to understand it for them. My brain has done automatic garbage collection after reading the various Xt texts, and I couldn't start writting a program using Xt. Although I think that X it pretty good up through the Xlib layer, seeing that Xt has become a stated underlying standard makes me have to realize that those defining the standards haven't yet understood the issues that will make X and Unix mainline consumer products. The Xt solution increases complexity when it should be a high level distilled usage of Xlib. Programmers out there don't want more complexity, they need less. Why do you think that software never catches up with hardware advances? Maybe the software isn't simple enough to use... Unix will be a bane rather than a blessing if no one decides that "engineering solutions" aren't wide market solutions, and works on productizing Unix for real people rather than expert users. Creating a barrier to learning and progress like the Xt gobbledygook is bad enough in itself (sorry Ralph). 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. If we want X to win then why is the door shut to creativity beyond the Xt class based model? Sorry to sound so negative, but I don't think that learning and creating the interface should be 80% of the application development time. I have created interfaces for large X applications in the past and don't think Xt (or Interviews) based solutions will work. I would really like to see an Xt based application with >100 windows, dialogs and alerts. By that time those teams of programmers designing and implementing widgets will have more than consumed the `peace dividend' in time spent learning Xt and subclassing widgets! The Sun solution of XView and Guide presents an example where the same basic functionality of the interface mechanisms have been created sans Xt. Last I checked InterViews didn't use Xt. Since there are multiple ways to skin this cat, and you state that Xt isn't the final solution, why is it a standard? -Jim Becker These thoughts are my own, and will probably get me into major trouble.. -- Jim Becker / jcb%frisbee@sun.com / Sun Microsystems ...these are my opinions, and even my id disagrees..