Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!frisbee!jcb From: jcb@frisbee.Sun.COM (Jim Becker) Newsgroups: comp.windows.x Subject: Re: Why do so many "great" people dislike X? Message-ID: <141973@sun.Eng.Sun.COM> Date: 6 Sep 90 22:25:49 GMT References: <9009041354.AA03267@armory> <1990Sep4.202433.19653@wrl.dec.com> <1990Sep4.180100@unify.com> Sender: news@sun.Eng.Sun.COM Lines: 101 raveling@unify.com (Paul Raveling) writes: In article <1990Sep4.202433.19653@wrl.dec.com>, kent@gilroy.pa.dec.com (Christopher A. Kent) writes: > > Jim Fulton says that X's worst failing is probably its dependency on the ^^^^^^^^^^ Jim Frost of Saber. > pixel as the base unit. I'd be tempted to agree, ... For a different perspective, my view of X's biggest problem is its complexity, most of which follows from the basic design goal of making it policy-free. I believe the ideal window system would use a fair bit more encapsulation of policy to keep the client interfaces clean, while still providing adequate handles to override important aspects of default policy. I strongly agree. This is where the direction of X after the creation of the Xlib layer appears, IMHO, to have gone astray. Instead of encapsulation of functionality, and introduction of solutions from the top down to the bottom, the Xt based stream of additional complexity was intertwined with that defined by Xlib to further multiply the base knowledgeset necessary to utilize the X Window System. In simple english, instead of making it easier to approach from a high level viewpoint, we now have more dribbling lowlevel functionality in the Xt Intrinsics and toolkit land before getting a real interface put together. The complexity of Xlib itself isn't really difficult, although there could be simple improvements (IMHO). 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. 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. This level of detail should be handled by the `User Interface System' as a whole, with little application programmatic overhead. Considering we have some of the brightest minds out there making these strategic decisions, I'm really surprised this is the current situation. A particular stumbling block is implementing policy through a separate window manager process, which adds some heavy burdens in communication and synchronization among client processes, the display server, and the window manager. I think a better way to do this is to make policy arbitration a central module within the main display server process, more like a ddx component than a client program. I strongly agree. What is needed is a higher level User Interface System/Server than handles everything. The separate window manager, and the `each application uses it's version of a toolkit' strategy, makes things a lot tougher in terms of user environment consistency and interaction. With a central server mechanism, issues currently handled inconsistently by the toolkits and window manager would become moot points. Additionally Internationalization would be consistent and easier, as well as user defaults and color management. 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. Although I don't program either, both systems seem to have higher level interactions between the user and the applications in manner of environment. X is dealing at granular levels, fighting upward. 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. It would be nice if that was more the norm in the X world. There is no reason that X could have not gone on this path in the past. [In fact I have developed a system with this philosophy on X.] However, with the combination of the current standards process and legal concerns (LAF), there are ramifications on pure originality and creativity for other potential solutions. It seems there is little room to break from the current defined alternatives, and the community has to work within them. Hopefully there will be lessons learned from the premature introduction of standards in the creative process. And hopefully the end result of ongoing legal battles in the computer world will not function to extinguish the innovative flame that has been kept alight by bright ideas and hard work. Hopefully. (it didn't look like a soapbox when I got on!) ------------------ Paul Raveling Raveling@unify.com -Jim Becker [Obviously my own opinions, not those of Sun Microsystems.] -- Jim Becker / jcb%frisbee@sun.com / Sun Microsystems