Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!sun-barr!newstop!sun!argv From: argv@turnpike.Eng.Sun.COM (Dan Heller) Newsgroups: comp.windows.x Subject: Re: where X went wrong Message-ID: <142074@sun.Eng.Sun.COM> Date: 9 Sep 90 21:08:20 GMT References: <141973@sun.Eng.Sun.COM> <9009091549.AA21182@expo.lcs.mit.edu> Sender: news@sun.Eng.Sun.COM Organization: O'Reilly && Associates Lines: 82 In article <9009091549.AA21182@expo.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > The > addition of Xt seems like adding macros to assembly, metaphorically, > rather than building high level structured languages and interface > generators. ... > Building from this base simply has created a really tough learning > curve, compared to providing systems at the level of HyperTalk and > 4GLs. There is simply too much the application programmer has to > understand to get to first base. > Most people will agree completely with you. But the problem is not a simple > one. Xt serves as a common base for multiple vendors with competing products. This statement should probably be emphasized more. Many people see Xt as a monster that will take years to understand well enough to write worthwhile applications. But the complexity in writing a real product-ready application is such that such complexity will eventually be realized whether it goes thru Xt or not. It just so happens that it becomes easier when you use Xt-based toolkits (or other well-developed toolkits). And perhaps this is meta level you're referring to when you say that the problem with X is that it doesn't provide this level of abstraction. should a company that sells monitors subscribe to a particular GUI or (gasp) API? The position X is taking is somewhat similar -- we'll provide you the means to display what you want, but you have to decide what to display. As for 4GLs, I have yet to see a respectible 4GL that will allow me to do the things I want to do and to leave me alone about things I am not concerned with or that I want to do differently (e.g. databases). > While it is conceivable to think of some variation in history which would > have resulted in a single high-level API (and perhaps a single GUI) in the > UNIX market, it is rather difficult to think of a realistic one. If you > have ideas on how it could have been accomplished (at a political level, > not just a technical level), I'd be interested in hearing them. Surely you jest :-). At a "political" level? Even if it were possible, I don't think the X consortium wants to be in that position. Technically, I think it is possible because of how X has been accepted and the committment the industry has towards it. It would be interesting to see what would happen if those who were completely independent of OSF, Unix International (the openlook group) and all the others decided to step back and evaluate all the good and bad about the UI's and API's available. They would then come up with what they feel is the "best of all worlds" and (regardless of whether or not it actually *was* the best), the X consortium adopted it and stamped it with the seal of approval. "This is the UI and API that has been blessed by the X consortium." Note: Xt would still be around, and X maintain its current status of providing mechanism, not policy for its windowing system. But, looming overhead is this new GUI and API. The interesting question is -- will people accept it by the mere fact that it came from the same folks that gave us X? I have been exposed to companies that choose Motif simply because they feel it's the accepted standard. Many of them also feel that in order to sell their software, they must provide it under Motif because "more hardware vendors support it." Both of these falsehoods are a result of powerful marketing tactics by OSF. (The other side hasn't been completely innocent either.) But, if the X Consortium chose Mope-and-Look as the "standard" GUI, then we could put this whole thing to rest, could we not? Who knows -- because this hypothetical situation will never come up and for good reasons: > Perhaps because the goals and requirements of the decision makers didn't > match yours? .. > And other major problems solved by the toolkit/WM method would in turn > become major problems again. :-) ... > My experience so far suggests that nothing makes internationalization > easier. :-) ... > X standards have progressed bottom up, true. Because that's where it has > been possible to obtain agreement. The upper layers, where end users care, > are fraught with politics (just consider what has happened in the IEEE P1201.1 ...and many others. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.