rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/09/90)
Where things broke down is not
taking a higher view of the interface creation process and building
systems which generate and manage the interface at a meta level.
If you talk to the designers of Xt, I think you'll find they assumed from
the start that there would be higher-level interfaces (e.g. an interface
builder at a minimum) wrapped around Xt and the toolkit. Prototype
interface builders for Xt toolkits were done years ago, I believe. But
their absence doesn't really negate the utility of having an Xt-like layer.
The
addition of Xt seems like adding macros to assembly, metaphorically,
rather than building high level structured languages and interface
generators.
I would think that many existing systems have an "intrinsics" kind of layer,
although it might not be cleanly factored out as such.
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.
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.
Considering we have some of the brightest minds out there making these
strategic decisions, I'm really surprised this is the current situation.
Perhaps because the goals and requirements of the decision makers didn't
match yours?
With a central server mechanism, issues currently
handled inconsistently by the toolkits and window manager would become
moot points.
And other major problems solved by the toolkit/WM method would in turn
become major problems again. :-)
Additionally Internationalization would be consistent and easier...
My experience so far suggests that nothing makes internationalization
easier. :-)
To me it isn't any surprise that the existing systems in use by large
numbers of end users are the Mac and Windows 3.0.
Not surprising to me either, since the hardware platforms they run on
constitute by far the bulk of the market. :-)
Although I don't
program either, both systems seem to have higher level interactions
between the user and the applications in manner of environment.
Hmm, I'm not sure I see this. Perhaps you are comparing a "complete system"
on the Mac or PC, with the "X standards". Not exactly a reasonable comparison.
The X market is quite different in structure (multiple vendors competing at
the GUI/API level) from the Mac/PC market (single vendor with dominant control
of the GUI/API).
X is dealing at granular levels, fighting upward.
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
group).
The solutions out there
for the masses give the end user a top-down approach, and therefore a
more warm fuzzy feeling of security. They are consistent in
appearance, and plug/play correctly. And are easy to setup and modify.
I find the Mac quite difficult to deal with, but then perhaps I'm weird. :-)
I find quite often that I simply accept the inability to modify.
It would be nice if that was more the norm in the X world.
Sure it would. How would you propose to solve it? I'm sure OSF and UI and
NIST and X/Open and IEEE and ... would love to know what the solution is. :-)
There is no reason that X could have not gone on this path in the
past.
Perhaps you'd like to write a paper on the subject, I'd be interested to
read it.
Hopefully there will be lessons learned from
the premature introduction of standards in the creative process.
This is an interesting statement. X did not introduce high-level
standards early on. This was supposed to help the creative process
(permit exploration of different user interfaces). In that regard
I think it has succeeded rather well: if there weren't so many options
to choose from, it wouldn't be so hard to get a standard. :-) It would
be interesting to know more about how you think things should have
progressed, and whether it would have enabled the same level of
creativity in toolkits, UIMSes, window management styles, desktop styles,
GUIs, etc.argv@turnpike.Eng.Sun.COM (Dan Heller) (09/10/90)
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.
ea08+@andrew.cmu.edu (Eric A. Anderson) (09/10/90)
I have programmed on three different windowing systems. The Mac, X,
and SunView. Of the three, I preffered Sunview the most, because I was
able to do a great deal without having to learn very much at all. In
sunview, I could create a complete application in very few lines, and
when I wanted more control, I was able to get it by learning more.
The argument that the Mac is better because it is consistent is somewhat
fallicious. Programming on the Mac, and in X is very similar. They
both use the same structure. At the current point, the mac has a number
of things available, which are somewhat like a toolkit, but much less
flexible. I do not really believe that X went wrong at any point, it
was written for a completely different environment. Show me the Mac or
Windows program that can run on one machine and display on another.
Something which is remarkably trivial in X. Show me how easy it is to
configure either the Mac or X. It is incredibly hard. You need to add
additional programs and other things to make it more configurable.
----------------
I think the primary problem with X is this : It is being programmed by
people working in their spare time. Apple had many people work for a
long time to create the Mac, ditto with IBM, and Microsoft. X has had
college students finding free time to do some sort of a program, and
because of this there has been no standard as to the way things will
work. Both Motif, and Open Look will change that, these two groups are
spending people and money to get their products to market. As such,
they are generating a consistant user interface. If all of the X
clients had had people who were being paid to do their work, and it was
being done by a single group, I am sure that they too would have a more
consistant interface.
By all means though, if anyone out there wants to define a seperate User
Interface, and redo all of the clients to conform to it, I think that
would be wonderful, but I doubt that anyone will have the free time to
do this.
-Ericrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/10/90)
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.
I didn't say the X Consortium would have anything to do with it. (Can't I
be interested in something with that particular hat taken off? :-)
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.
If you mean technical experts in this area, face it, the result would be
that you'd end up with 10 toolkits/GUIs to choose from, instead of 2 or 3. :-)
They would then
come up with what they feel is the "best of all worlds"
The end users I've talked to don't have much interest in the "best of all
worlds". They just want something that works, so they can get on with it.
Any of the commercial toolkits available today would likely be acceptable
to them.janssen@parc.xerox.com (Bill Janssen) (09/11/90)
The end users I've talked to don't have much interest in the "best of all worlds". They just want something that works, so they can get on with it. Any of the commercial toolkits available today would likely be acceptable to them. This point, coupled with the MIT X11Rx releases, has caused much consternation around the technical community. Many people who are ignorant of the history and goals of the X project expect "X" to give them a standard environment. Of course, the MIT X release has no standard environment. xterm works one way, typescript another; xemacs does not behave like idraw. But it is not so much "X" that has failed them, as it is the particular path to "X" that they have chosen. Perhaps there should be more advertisement of the fact that MIT X11Rx does not provide a windowing environment (in the Mac/MS-Windows/SunView sense of the term), but rather a toolset with which such an environment can be constructed, and one or two examples of what an environment might look like (eg. Andrew). Many sites are quite happy in standardizing on Motif or OpenLook, and treating their choice as *the* "X" system. Policy is provided, there is a standard toolkit, all the applications play together. Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/26/90)
I think the primary problem with X is this : It is being programmed by
people working in their spare time.
Gee, I guess I should stop working weekends, so I can live up to this.bret@codonics.COM (Bret Orsburn) (09/26/90)
In article <cauhvVC00VpZ4yI0Ua@andrew.cmu.edu> ea08+@andrew.cmu.edu (Eric A. Anderson) writes: >I think the primary problem with X is this : It is being programmed by >people working in their spare time. Apple had many people work for a >long time to create the Mac, ditto with IBM, and Microsoft. X has had >college students finding free time to do some sort of a program, and >because of this there has been no standard as to the way things will >work. The MIT X Consortium is primarily an industry group. (Check your Xconsortium man page for a fairly recent list.) >Both Motif, and Open Look will change that, these two groups are >spending people and money to get their products to market. As such, >they are generating a consistant user interface. If all of the X >clients had had people who were being paid to do their work, and it was >being done by a single group, I am sure that they too would have a more >consistant interface. The X Window System is not intended to provide a consistent user interface. It is intended to provide a set of capabilities on which any number of user interfaces can be built. -- ------------------- bret@codonics.com uunet!codonics!bret Bret Orsburn
sarima@tdatirv.UUCP (Stanley Friesen) (09/26/90)
In article <cauhvVC00VpZ4yI0Ua@andrew.cmu.edu> ea08+@andrew.cmu.edu (Eric A. Anderson) writes: >I have programmed on three different windowing systems. The Mac, X, >and SunView. Of the three, I preffered Sunview the most, because I was >able to do a great deal without having to learn very much at all. In >sunview, I could create a complete application in very few lines, and >when I wanted more control, I was able to get it by learning more. In that case you will probably want to do your X programming using the XView toolkit, which is nearly identical to the Sunview interface. (The main difference is that all the XXX_ prefixes are replaced by xv_). (Really try it, you can almost use the Sunview manual) Of course this generates an Open Look GUI program, but I do not consider that a problem. ------------------ uunet!tdatirv!sarima (Stanley Friesen)