X Window System Users and Developers Conference, Day 1 [1/4] 1/14/1987

MIT 150 | Project Athena - X Window System Users and Developers Conference, Day 1 [1/4] 1/14/1987 [MUSIC PLAYING] SCHEIFLER: Good morning. My name is Bob Scheifler. And on behalf of MIT, the Lab for Computer Science, the MIT X Consortium, Project Athena, and other sundry people, I welcome you to the Bahamas. Registered attendance for this conference was in excess of 1,000. So a few people probably are frozen somewhere in between wherever they are and here. We have a lot to get through, so I'm not really going to say much more. I'm going to ask that the speakers introduce themselves as they come up, so that I don't have to keep bopping up and down. Due to technical difficulties, we're going to have a slight rearrangement of the morning agenda. So without further ado, we'll go into our first talk. BOWBEER: Just a second here. Hi. I'm Joe Bowbeer from Apollo Computer. When you start up most window systems, they take over the whole screen. The sample server takes over the whole screen. At Apollo, we're interested in integrating the X server, so that it shares the screen with other window systems. If x, y, and z are window systems, we'd like x, y, and z to coexist on the same screen. We'd like the user to be able to access x, y, and z windows on the same screen. Let's see, first slide. One back, please. PROJECTIONIST:How's that? BOWBEER: Yeah, I have the master control here, I think. Sorry about this. There you see an example of the Apollo window system. When we shipped our first node in 1981, it came with a window system on it that was shipped to Harvard University. And I was still in school at the time. And so our customers have had seven years to develop code, which uses and requires the Apollo window system. So the first reason we want to try to have X share the screen with other window systems is so that we can give our customers X windows without taking away their old window system. The second reason is functionality. In this example, you see 3D graphics, in a window on the left, and Interleaf Text Publishing System on the right. We used Interleaf, as you can tell, to do the slides. And 3D graphics, it's an example of something which is available in the Apollo window system, which won't be available in X for a while. Interleaf is an example of a complex application, which may take some time to port to X. In general, window systems have their advantages. And we want to try to offer all the advantages at the same time. Another reason is extensibility by integrating the window systems together, we have a platform to which new window systems can be added in the future. This is an X screen. It's rather sparsely windowed, because I'm leading up to something. We've got X clock in the corner and X term down in the bottom. Just a minute here. The on/off switch-- there you go. Now the question is, what do you get when you put two window systems together? Here's one idea. If you integrate them at the video level, it's sort of x plus y over 2. I don't think special glasses will help with this one, either. Here's an example. I meant to unobscure of the X windows. They're both unobscured. Sorry, I meant to obscure one of the X windows. They're both unobscured. And that's how you can tell this is a real slide and not a fake one. Because if I'd faked it, I would have obscured one of the windows. Let's see, there's that. Did you see that? That's what you get. This is one of those three part talks. I'm going to talk about the strategy for doing this. And then a little bit about the implementation, and then I'll conclude. First of all, how are we going to integrate these window systems or how did we integrate the window systems? You can consider three options. One is, if they were all server-based window systems, you could merge them at the protocol level, just merge the protocols together, make one big super server that does both of the things. Unfortunately, window systems are not all server-based. There are procedure-based window systems. The Apollo window system is an example of this, where the window and graphics routines are in a library, and the application is called directly into the library. So then we go on to number two. You can layer one window system on the other. In this case, you would layer the procedure-based system on the server-based system. The problem here is, one, you're going to degrade performance in the procedure-based system, because you've introduced this additional layer. Two, you're probably going to have compatibility problems, since you've reimplemented most of your procedure-based system. Three, there's also a problem with direct memory access to the screen. Procedure-based systems often let the applications directly manipulate the bits in the screen, and that's something that server-based systems can't do without some fooling. So we get to number three, which is to build a shared window system nucleus, build a window system nucleus that all the window systems use. Before I get on to the implementation, let me talk a little bit more about what this means to have shared window systems. One point, by sharing the window system nucleus, all the window systems can access all the windows on the screen, even the ones they didn't create. In this example, you see the x window is the root. There's a y window, one of the children, a z window, one of the children. And if you run an X window manager, for example, you'll be able to move and resize the x window and the y window. One of the tasks in integrating a window system is that you need to fix it so it doesn't lose its mind if it sees windows that it didn't create. The other point about this is that, if you say, use the X window manager to change the size of the y window, then the y window system, because it's sharing the nucleus, will find out about those changes. And another thing you have to do when you integrate window systems is to fix it so it doesn't lose its mind if someone else changes one of its windows. We give the window system that created the window squatter's rights on the window. That is the window system that created the root, being the X window system, gets to control the background pattern and the cursor shape and the border width. You can run two window managers at once. But we don't think that's particularly useful. So we aren't trying to bend over backwards to make that work. We only support one window manager at a time. You might also note that, if the integration is done correctly, then you could run two X servers on the same screen. If anyone knows why you'd want to do that, I'd like to know. Now, in order to build it, the shared nucleus, you to find out what things have to be shared. And here's a list of the things we have thought of. You need to share the window database, so that every window system can access all the windows and find out about changes to the windows they care about. You need to share the input. You need to share screen resources, the graphics controllers, the screen memory, the color lookup tables, the screensaver, and the mechanism that turns off your video if you haven't talked to the screen for a while. That all needs to be shared. Also selections, for example, we'd want to be able to cut and paste between windows of different window systems. I'll talk more about the window database and input in a minute. As far as screen resources, the graphics controllers and screen memory, you just need some sort of fair dispatch mechanism that will give every window system a chance. The color lookup table, we're implementing a superset of the X color model and having X use that. Here's what we need to share in the window database, the position and size of the windows, so that one window system can change the position and size of another window and that will all work. The window clip region, an x window can obscure a y window, and that needs to be handled at the clip region/stage. Parents, siblings and children-- you can have an x window as a parent of a y window and vice versa. The class, input-output or input-only, this determines how the clip region is computed. And the status information, such as these flags, such as exposed, obscured, match, also an indication of whether the window has been changed recently. For example, a flag that tells you whether the position has changed. Note that there is no border width in the window database. Every window system needs to augment the shared database with its own special needs.

Load more