> Why spend time putting a bag on the side of X, even if it will never be entirely
> what you want? Why not just work on developing a new system that will be all
> the things you want, and more extensible and powerful too? I'd hack X if I
> thought that it was a good platform...kinda along the lines of Linux, why
> hack Minix into something that it'll never be really good at? You have to take
> a running stab a completely new model, that's what Linux was.
IMHO all that trouble can be avoided if some clean interface will be
designed between high-level "thicker display" and X. If the original
implementation will be capable of sitting at the top of X as a library on
the client side *and* as a proxy on remote server side *and* as an
extension to the X server, compatibility problem will be nonexistent, and
code, developed with new library will simply load additional shared
library if the X server doesn't have the extension, it requires. Of
course, "display-side" implementation can be done in some more "hackish"
way than as high-level-to-X proxy, it may benefit from some (reasonably
sane) messing with X server internals while not turning it into something
incompatible with X or breaking portability. Non-X-based "thicker display"
server can be developed separately, with or without X, GGI or whatever
other code, and still will be compatible by protocol with one, developed
as X server extension. And if that will be done, nothing will prevent for
compatibility reasons to allow running X server on this display, too --
but as an unrelated piece of code, using the same low-level graphics
library and taking/sending events using different part of the same
protocol when talking to X clients -- it will be kind of microkernel of
GUI systems.
-- AlexP.S. and if that thing will be done, and it will be possible to extend it easily, there will be no problem optimizing such horrors as, say, AWT -- native methods of it will be implemented in that display as yet another server, and goodbye Motif-based JDK.