''Copied from XwindowProtocolShouldBeStabbedAndBurnt''

My vote, since the mid-eighties, has been to replace it (X11) with "STEWS" -- the Smalltalk Extensible Window Server. For those who remember the NetworkExtensibleWindowSystem, picture NeWS with SmalltalkLanguage as the extension language instead of PostScript.

Here's what STEWS might look like:
	* Postscript-based Image Model (splines, areas, paint, etc. instead of pixels).
	* Display Postscript as the required minimal primitive set, with whatever additional features a vendor wants to provide
	* Smalltalk message/block as the API
	* Window Server is dynamically extensible in Smalltalk
	* Industry-standard API's supported (OpenGL, X11, CommonWindows, etc)
	* Three-D primitives

Given the above, I think (I haven't thought this through, though) that it would be easy to integrate STEWS into the various approaches to distributed processes (DotNet, ActiveX, Corba, EJB, etc).

-- TomStambaugh

''Does STEWS handle network transparency like X11?  Without that, it (or anything)  isn't much of a replacement...''

STEWS would (like every unbuilt system, it always works perfectly) be transparent, for several reasons:

	* It would presumably talk the X11 protocol (an X11 client should be unable to distinguish a STEWS server from a regular X server.
	* It would support other protocols as well (most recently, I wonder about XML/SOAP).
	* Because the server would be extensible, new protocols or changes and bug fixes to existing protocols would be readily installed by clients.

Again, picture NeWS but with SmalltalkLanguage instead of DisplayPostscript as the extension language.

----

OK, so it is written in Smalltalk ''and'' it still supports the complete X11 protocol ''and'' it supports N other protocols, some of which (XML) with ridiculous inefficient encodings, ''and'' it is user extensible, ''and'' it is supposed to be less bloated than X?

I am sceptical. At the end of the day, when you look at its full functionality, X is not bloated.

-- StephanHouben
----
I made no claim that STEWS would be "less bloated than X", nor did I claim that X is "bloated". The problem with X is not that it is "bloated", it is that it was obsolete when it was introduced and has fallen further behind since. The "full functionality" of X barely supports Mac-style graphics from the mid-eighties. Tell me again how I put up a non-rectangular window? How do I go about making the non-geometric object (Mike Smith's face in the group portrait, for instance) in my scanned image clickable?

I can make ANY piece of code small and lightning fast if it doesn't have to work.

-- TomStambaugh


As a matter of fact, I am editing this page from a Windows peecee on which Internet Explorer runs a Java applet that connects with the VNC protocol to an 
X server on my Linux machine, which runs a full KDE environment.

This is a set-up I use daily, and it is only workable because of the power of X.  

''this shows the power of VNC not X ???''

''Sure - nothing to do with X. You can connect to a Windows box using VNC in exactly the same way.''

And BTW, yes X can do non-rectangular windows, see the XShape... functions. The statement about Mac-style graphics is too silly to require rebuttal.

-- StephanHouben

What do you mean by "create a non-geometric object"?

If you want to make a face within an image clickable, there are several approaches you can take:
	* Create a bitmap that represents the face you want to be clickable. In your client, react to mouse-click events by checking whether the mouse pointer is over a sensitive pixel, as defined by the bitmap.
	* Do the same thing with a region object.
	* Create a non-rectangular, input-only window that is the same shape as the face you want to click on. (Input-only windows are invisible and only serve to collect user input). Place it over the face you want to click on. React to mouse clicks on the input-only window.

I'd go for the latter.

-- unsigned

----

"STEWS would (like every unbuilt system, it always works perfectly) be transparent, for several reasons:"

XwindowServer''''''s can be built in something as small as a few hundred kbytes, operating in a small, fixed amount of RAM, and they are fast and can be secured pretty easily. We know what you get when you put a ProgrammingLanguage on the server because we have seen it several times before: DPS, NeWS, and Java (Java is basically NeWS-TNG). You end up with megabytes upon megabytes of stuff in the server, heaps that grow without limit, the need for a SafeVirtualMachine, the need for potentially huge amounts of memory, and rather tricky communications between the application programmer's GuiToolkit and the server-side application written in a completely different language.