Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!wse.dec.com!mwm From: mwm@wse.dec.com (Mike Meyer, My Watch Has Windows) Newsgroups: comp.society.futures Subject: Re: Grumpy about Dopey Window Systems... Message-ID: <9102202334.AA29496@fenris.pa.dec.com> Date: 20 Feb 91 23:34:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 87 Hello agan, Barry. I've been meaning to reply to this for a couple of weeks, and just kept getting distrated. Anyway... >> That's not buggy applications which don't properly accommodate >> different screens. That's an expression of a real philosophy in X that >> the end-user can set all these things so why bother to think about >> them? Take it as an example of what's wrong I think this is wrong. Not that X isn't broken, but the implication that the application writer should worry about building the interface, and the end-user should have limited power to change it. If that's not what you're implying - well, I want to wave my ideas around anyway, and this is a good chance :-). The reason application writers shouldn't worry about interfaces is that progammers are notoriously bad at interface design. They tend to build interfaces that make lots of sense - to someone who knows the internals of the program, and thinks like the programmer. My beta testers complain about such things regularly. I then see other programers doing the same things I corrected (and curse at them, because I like the interface my beta testers forced me to build). Second, the end user should have as much flexibility as possible - the more, the better. I claim that emacs is so successful not because it offers an incredibly overgrown set of tools, nor because it's the perfect editor, but because it allows anyone with a little smarts to build an editor to their taste. I feel the same should apply to the user interface parts of a windowing system. >> What I'm looking for here is, what will be the third generation of >> windowing systems? How will we get back to some sort of rational set >> of primitives and away from the burgeoning laundry lists of features >> which belie no wisdom about the underlying goals, just zillions of >> little knobs to turn in a frantic attempt to make everyone happy (and >> succeeding in making no one happy.) Others have claimed that X, underneath the layers and layers of cruft, isn't a bad set of primitives for a windowing system. I'm willing to believe that - because I'm more interested in the layers and layers of cruft, and fixing them, than I am in what actually happens to render a pushbutton. In other words, replacing xtk, motif, /usr/lib/X11/app-defaults, and .Xdefaults with something useable, rather than trashing X completely. I've been working on a system that would do just that - except I'm not using X as a base. The key insight is that many applications don't really need to deal with a "user interface" per se. They need to get values from the user, display data, and act on commands issued by the user. If you let "get values" include file selection boxes and text editing widgets, a broad range of applications fit the paradigm. For such programs, the application divides cleanly into an "application", and a "user interface". The application has entry points for the commands, code to display data, and hooks for setting values. The UI has gadgets for issuing the commands, setting values, and drawing areas for displaying the data. The application really doesn't care about the UI, only about the values and commands that come back from it. Using what I'm working on, a typical application has two parts, ala a Macintosh. However, the "resource fork" is a spec for the _entire_ user interface. The equivalent of a "resource editor" would allow a user to re-arrange the entire interface - moving or deleting menus, turning radio buttons into mutex menu selections or cycle gadgets, putting commonly used commands on keystrokes or control panel buttons, etc. The format of the "resource fork" will be public, so anyone can write an editor for the thing. There are already a couple of different editors under construction. Tieing the two forks together will be the library that actually implements the UI based on the spec. The application will - naturally - depend on the library. Some of the strings in the GUI will also depend on the interface, and those wouldn't normaly be edited. For each library, there's a file of the same format as the resource fork (so the same parser can be used) that's used for setting defaults for applications that use that library. This isn't really much different from the app-defaults approach that can be taken with X. The major differences are that it forces an application to use this approach, and that the "resource database" isn't a collection of baroque strings with obscure precedence rules. It may be possible to build such a system on top of X; I'm not trying to. In fact, I'm working in a single-user environment. A multi-user environment has some obvious extensions with not-so-obvious flaws in them.