nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (02/01/90)
Excerpts from internet.xpert: 31-Jan-90 Re: Abstracting the Windowi.. Benjamin Ellsworth@hplab (2065) > This is a hopeless task. It's not that it can't be done, but the impact > to the product and the costs of even coming close to making it work are > at least as great as the costs of moving to newer standards. I speak > from experience with user interface systems, business applications and language systems. I can't agree with this. There are tradeoffs that can be made. In particular, if you are willing to settle for doing without some of the fanciest functionality of any given window system, it is possible and productive to define a window-system independent layer on which to build your software. As proof of this claim, consider the Andrew software. It runs daily on two different window systems (the old WM developed in the Andrew project, and X11). WIth X11R4, they even run at comparable speeds and robustness (this was not true of the previous release). The code has also been partially or fully ported to at least three other window systems, to my knowledge. The secret to Andrew's window-system-portability is that it defined a portable graphics layer that mapped well onto multiple window systems. Using this model, you can't get at every bell and whistle of X11, but you really do get portability without paying a significant performance price. (With Andrew, you even get binary compatibility -- the same binaries will run on multiple window systems, and can even, I believe, open an X window on one display and a WM window on another. Now *that's* portability!) The Andrew Toolkit and many application programs are available on the X11R4 tape under "contrib/toolkits/andrew". -- Nathaniel S. Borenstein Bell Communications Research
dshr@SUN.COM (David Rosenthal) (02/02/90)
> As proof of this claim, consider the Andrew software. It runs daily on > two different window systems (the old WM developed in the Andrew > project, and X11). WIth X11R4, they even run at comparable speeds and > robustness (this was not true of the previous release). The code has > also been partially or fully ported to at least three other window > systems, to my knowledge. > > The secret to Andrew's window-system-portability is that it defined a > portable graphics layer that mapped well onto multiple window systems. The secret to Andrew's portability to X11 is that X11 was designed from the start to be capable of supporting Andrew because some of the people who designed WM also helped design X11. If you want to make this case, you need some less contrived example. David.
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (02/02/90)
Excerpts from mail: 1-Feb-90 Re: Abstracting the Windowi.. David Rosenthal@Sun.COM (799) > The secret to Andrew's portability to X11 is that X11 was designed from > the start to be capable of supporting Andrew because some of the people > who designed WM also helped design X11. If you want to make this case, > you need some less contrived example. Hey, did you read the whole message? If it were just Andrew & X11, you'd have a case. But there does not appear to be any problem with porting Andrew to NeWS, NextStep, PM, or MGR, a rather wider family of window systems. Each of these ports has been started or planned, though none have been pushed to the form of released products. The fact that nobody has polished up and supported these ports is, as far as I know, more political than technical -- nobody has been motivated to do so. I think you've got some of the history wrong, too, David. The Andrew portable graphics layer was designed *AFTER* X11 -- after you left the Andrew project, in fact. (Reading the NeWS book, one could easily conclude that Andrew was unchanged forever from the time you & Gosling left, but this is very far from the truth.) It was designed when we ported Andrew to X11, but was explicitly designed to make other such ports extremely easy. I stand by my claim that the Andrew portable graphics layer is a good existence proof for the plausibility of window-system-portable code. You sacrifice the whiz-bang aspects of each window system in favor of portability across many of them. I challenge you to find any reasonably modern window system that can't support the Andrew graphics model, as defined largely in $ANDREWDIR/include/atk/graphic.ch on any installed Andrew system. -- Nathaniel Borenstein, Bellcore.
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (02/02/90)
> I can't agree with this. There are tradeoffs that can be made. In > particular, if you are willing to settle for doing without some of the > fanciest functionality of any given window system, it is possible and > productive to define a window-system independent layer on which to > build your software. > > As proof of this claim, consider the Andrew software... Yes you can address performance, but at the price of design and maintenance, and even then there is a limit. The more general the backend of the interface the more complex the work that it does. The only way to eke that last drop of performance out of the box is to talk straight to the hardware, but then you lose vendor-neutrality. If, on the other hand, performance is not a critical problem and you are willing, for all intents and purposes, to write and maintain your own window system you can do wonders; look at X. There is a DDI layer which the server operates from, and generally that's just fine. HP (and other vendors with high end graphics hardware products) couldn't just wedge their sophisticated functionality into the server/DDI, and so special windows that are controlled by the special purpose hardware are available. I'll bet that your use of X is not much more sophisticated than as a graphics and input library. All of the other "windowing" work you do yourself. You have to some degree (perhaps a large degree) written your own window system. My comment about hoplessness had to do purely with business issues. I assume that the management is concerned with engineering resources being consumed as window system standards change. I'm making the point that those resources are either consumed during the change, or they are consumed during the design, development, and maintenance of the "interface layer." The idea that there's a free lunch lurking in this "interface layer" approach to multiple-backend support is hopeless. Please note that the idea of interface layers is not useless (I write widgets which essentially provide and interface layer ;-). If one has decided upon a single backend (most people do only a single front end), then an interface layer becomes a side effect of proper design -- it becomes a level of abstraction within the design. Ideally you have a single standard to build upon and your program starts from there. You then avoid the design and development headaches, and you can pay someone else to do the maintenance. I think that's why the X Window System(tm) holds so much promise. If it takes over, we can dispense with that part (the interface layer) of our design, development and maintenance, and go directly to providing the value added by our programs. > -- Nathaniel S. Borenstein ---- Ben
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (02/02/90)
Yeah, there's less of an argument here than meets the eye. I didn't mean to claim that an abstract window system interface solves a lot of the problems you point out; I was merely taking issue with the notion that it couldn't be done, which was somewhat overstated. For a limited set of goals -- e.g. making applications that are not too graphically demanding be portable across a wide range of window systems -- it is certainly posible. That doesn't address the graphic-heavy users at all, nor does it solve a host of other problems. I don't think there's much left here to argue about. -- Nathaniel
mlandau@bbn.com (Matt Landau) (02/03/90)
dshr@SUN.COM (David Rosenthal) writes: >> The secret to Andrew's window-system-portability is that it defined a >> portable graphics layer that mapped well onto multiple window systems. >The secret to Andrew's portability to X11 is that X11 was designed from the >start to be capable of supporting Andrew because some of the people who >designed WM also helped design X11. If you want to make this case, >you need some less contrived example. There are one or two other examples. At BBN, the multimedia communications group (of which I'm a part) has its own toolkit for producing window-based applications. Our toolkit also implements its own abstractions for windows, events and event processing, menus, dialogs, and other user-interface components, for both input and output. Although our toolkit was originally written to run on top of SunWindows (yes, it predates the SunView programming interface), we've since ported it to X11, and in general applications simply recompile and run. It's true that we don't take advantage of ALL of the bells and whistles of X, but in fact we manage to make very good use of many of them. What's most important is that you view the abstract toolkit as an evolving entity that you can modify as you port to other underlying window systems. For instance, as we've ported our toolkit to X11, we've added new several abstractions and semantics to make the fit better (window groups, a model for transient vs. non-transient windows, etc.), then gone back and added the same abstractions to the Sun-specific version of the toolkit. In most cases, the result is that BOTH versions of the toolkit are improved by such additions. As proof of the fact that you CAN build a generic window system toolkit that's more than a toy, I will point out that we build our BBN/Slate product on top of this toolkit. Slate is multimedia document communications system that includes a document editor (documents contain text in English and other languages, graphics, monochrome and color images, spreadsheets, charts and graphs, voice annotations, and generic enclosures), mail reader and interface to the local mail system, and realtime conferencing system that allows multiple sites connected by TCP to examine and edit documents simultaneously in real-time. Both the user-interface components and the underlying conferencing architecture are implemented within our toolkit, and both run under SunView and X11 with no application-level source code changes. So it can be done :-) [Before anyone asks, I'll head off some questions: No, you can't get the toolkit sources -- they're considered proprietary software by BBN. Yes, you can buy Slate -- contact BBN Software Products Corp. for details and prices, 'cause I'm an engineer and not a salesman :-) No, it's not based on Andrew, although the two systems have some similarities and we've done some work with the Andrew folks in a reseach context. If you have other questions, email me directly rather than cluttering up the newsgroup.] -- Matt Landau Dancing with the Ice Weasels mlandau@bbn.com
barmar@think.com (Barry Margolin) (02/05/90)
I'm not going to get in the argument over whether or not this is reasonable
(but I think it is). To answer your question, Xerox and International Lisp
Associates developed a window-system-independent windowing interface,
called Solo, in order to implement CLIM, the Common Lisp Interface Manager
(a portable UIMS for Common Lisp systems). While the implementation is in
Lisp, the concepts of Solo are applicable to any language (CLIM, however,
is tied closely to Lisp). Sorry, I don't have the technical paper here, so
I can't tell you how to contact the developers.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmarSWM@SAPSUCKER.SCRC.SYMBOLICS.COM (Scott McKay) (02/05/90)
Date: 4 Feb 90 19:37:07 GMT
From: barmar@think.com (Barry Margolin)
I'm not going to get in the argument over whether or not this is reasonable
(but I think it is). To answer your question, Xerox and International Lisp
Associates developed a window-system-independent windowing interface,
called Solo, in order to implement CLIM, the Common Lisp Interface Manager
That's "Silica", not Solo. It was developed by Ramana Rao at Xerox, and
Bill York of ILA is now working on it with him in service to the CLIM effort.
(a portable UIMS for Common Lisp systems). While the implementation is in
Lisp, the concepts of Solo are applicable to any language (CLIM, however,
is tied closely to Lisp). Sorry, I don't have the technical paper here, so
I can't tell you how to contact the developers.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmarhmuller@cumulus.eng.sun.com (Hans Muller) (02/06/90)
> From: barmar@think.com (Barry Margolin) > I'm not going to get in the argument over whether or not this is reasonable > (but I think it is). To answer your question, Xerox and International Lisp > Associates developed a window-system-independent windowing interface, > called Solo, in order to implement CLIM, the Common Lisp Interface Manager > (a portable UIMS for Common Lisp systems). Solo is a project we're working on at Sun - it's a CLOS interface to XView and Xlib. At this point Solo doesn't have anything to do with CLIM, although you've characterized it correctly: it's a portable interface that supports basic window/image/font/color operations as well as user interface components like buttons and menus. I agree with the direction that the current discussion on this topic seems to be proceeding: building a portable abstraction of a window system interface (like Xlib) involves making some difficult performance and features tradeoffs. I think one way to take some of the bite out of these tradeoffs is to admit that some applications will carefully go behind the portable interface to get some special feature or extra performance. What you're really doing in this case is adding some application specific feature to the portable interface and agreeing to support it yourself. Naturally the cost of porting your application will increase according to the amount of behind-the-curtain code you write. > Sorry, I don't have the technical paper here, so I can't tell you how to > contact the developers. A paper about Solo appeared in the 1989 OOPSLA proceedings. It's not in the table of contents but it's in there. I'm one of the developers and you can contact me at HMuller@sun.com. Hans Muller