Goals Of Xwindows Discussion

Moved from ShouldXwindowsBeReplaced, where GuiMarkupProposal was suggested as a replacement for X. This was the response:

GuiMarkupProposal appears to be almost entirely irrelevant here. X provides the low-level infrastructure for obtaining user input from keyboards and mice and displaying overlapping bitmaps on display screens. GuiMarkupProposal is much more aligned with, say, either widget toolkits for X or Gnome and KDE, which are desktop environments built on top of X. Even the X window core protocol which provides network transparency is more aligned with (say) the HTTP protocol than GuiMarkupProposal, which is more about desktop and window contents than the underlying low-level machinery that X provides.

Well, maybe the problem is being solved in reverse. Devise a higher-level standard, and then let browser implementers worry about the details. Or do you want a browser-builder framework for implementors? If that's the case, why can't existing browsers be the basis of a replacement? Or is the browser viewpoint/approach being rejected here? Make a feature list to find out what people care about the most and the least, and then compare to existing tools for inspiration and anti-inspiration (FailureAnalysis?).

X has nothing to do with browsers. Browsers are built on top of widget toolkits, which are themselves built on top of X.

So complaints about X-windows over networks is moot because network handling is at a level above it? Are you describing how you prefer interfaces be partitioned, or how they must be partitioned due to some unstated rule/law?

No, complaints about X over networks is relevant, because X defines a network-independent protocol. GuiMarkupProposal is irrelevant, because it does not define any protocol and especially not one that would replace any part of X. An implementation of GuiMarkupProposal intended to run on UNIX/Linux machines would inevitably need to be built on top of a widget toolkit, which would itself be built on top of X. It could conceivably replace widget toolkits and X, but to do so it would need to be extended to describe both widget toolkits and the low-level screen/keyboard/mouse I/O that X defines.

Being network independent is not necessarily the same as being network-friendly.

True, but how is it relevant here? Particularly, how does it make GuiMarkupProposal relevant?

I cannot answer that because the context of X-window's replacement is not clear. There seem to be unspoken assumptions about how GUI systems and designs "should" be partitioned or will be partitioned, but those assumptions are not documented. X-windows assumes a certain partitioning, but perhaps we don't want to keep the same partitioning in the future. If we DO keep them, then document "why" in terms of alternatives. The division of responsibilities of the client-side versus the server-side when a latency-plagued network is involved is of particular concern to me.

The context of an X replacement is precisely what X does -- it provides low-level infrastructure for obtaining user input from keyboards and mice and displaying overlapping bitmaps on display screens. I can appreciate your concerns about network displays on a latency-plagued network, but it's not clear how GuiMarkupProposal has anything to do with that or X.

Re: "The context of an X replacement is precisely what X does" -- So all participants agree the goal excludes review of the system context that X-windows is usually used in? If latency-friendly tools/parts can replace it, then one can kill two birds with one stone: replace X and have a latency-friendly kit. OnceAndOnlyOnce in tool design. That seems logical to me. If not, let's document why it's not logical so it's clear to all in case the question comes up again. (GuiMarkupProposal may indeed not be relevant, but I don't have enough info about the big-picture goals to say for certain yet.)

The "system context that X-windows is usually used in" is a UNIX or UNIX-like operating system, to provide an interface to keyboards, mice, and display screens. Are you saying you wish to review the operating system? If GuiMarkupProposal doesn't show clearly how it's a possible replacement for X -- in the same way that WayLand and MirProject are replacements for X -- I suggest this whole threadlet be moved to its own page, say, ReducingRemoteDesktopLatency?.

At the bottom of GuiMarkupProposal, somebody talks about Java and DotNet as being possible replacements for some uses of X (I didn't write it). If a browser-based interface ("BBI", such as GuiMarkupProposal or the HtmlStack) can replace Java and DotNet applications, then it logically follows that a BBI can also replace X (in some cases, at least).

At the bottom of GuiMarkupProposal, somebody correctly points out that Java and DotNet are not a direct replacement for X, only that their applications -- which run on more than just X -- might target the same market as native X applications, thus making X appear to be less relevant. It's true that browser-based applications can replace Java, DotNet, and native X applications. However, on UNIX and UNIX-like systems, the browser itself relies on X. X abstracts the low-level UI devices -- mice, keyboards, screens. Graphical applications, like browsers, are built on top of X. GuiMarkupProposal is not even a proposal to replace the browser, but to replace the HTML stack inside the browser. That makes it not a replacement for X.

Some believe the future of most GUI's is through a browser. If we are talking about the base UI guts of a browser (or even a desktop GUI) then GTK+ could be considered a replacement. X mixes some network issues with it, and is thus competing with browsers.

The future of GUIs may well be through a browser. On UNIX and UNIX-like platforms, the browser is a graphical application. Graphical applications usually run on top of X. GTK+ is a widget toolkit that, like other widget toolkits, runs on top of X. It is not a replacement for X; it uses X.

X provides a network-transparent protocol for connecting an X server (usually a display terminal, with keyboard, mouse and screen) to X clients which run on a UNIX or UNIX-like host. Note the apparent inversion of the usual meanings of client and server, but it's correct -- the display is a server that provides graphical output and user-input services to the clients running on a central host. It was designed in an era (that continues today) when centralised mainframe UNIX hosts -- typically housed in a secure data-centre -- would be accessed via graphical X workstations in users' offices over a high-performance, reliable network. It provided a way of running a lot of workstations over a distance that video cards installed in the host couldn't reach. Monitor cables are only usable over short distances; mouse and keyboard cables will work a little further but not much. The network support in X is primarily an alternative to lengthy, specialised display cables and hardware; it was not intended to be a general remote facility. Thus, the X display protocol is no more a "competitor" for HTTP/Web browsers than a videocard and an HDMI cable.

Since modern desktop computing typically bundles the CPU and frame buffer (i.e., video card) in the same box, some replacements for X (the MirProject, for example) dispense with networked remote displays. Remote desktop capability -- which is quite a different thing -- is more effectively handled via RDP, VNC, etc. What your GuiMarkupProposal appears to cover is only widget layout. Thus, it would perhaps be a language for arranging GTK+ widgets in some graphical environment, like a browser. As such, it would run on top of GTK+, which would run on top of X (or its replacement). Thus, GuiMarkupProposal doesn't represent a replacement for X.

The talk of cables sounds like it's targeting archaic minicomputer models of work-stations. If it's a dying hardware configuration, then why bother to replace it with a mere semi-clone? Hop on the browser bandwagon. For high-end collaborative graphics, a PC could do most of the UI work and the server would be the database essentially. PC's are relatively cheap such that they trump custom nor niche graphics kits for relatively rare mini-computer-style workstation software. I'm not saying the minicomputer arrangement is inherently "bad", but rather the market-share and economies of scale are lacking to justify the effort of expanding and reworking the minicomputer model.

As I pointed out, some replacements for X (the MirProject, for example) dispense with networked remote displays; they don't implement X's network-transparent protocol. However, if you're going to run a browser, it will need to access display hardware and user input devices like mice and keyboards. It's quite unreasonable to expect a generic browser to embed low-level graphics and user-input device drivers, so browsers invariably run on top of a graphics and user-input abstraction layer. Under Windows, that layer is DirectX. Under UNIX and UNIX-like operating systems, it's X or its (eventual) replacement.

I agree it's progbably a good idea to divorce networking from low-level graphics handling. What about PostScript with some mouse/pointer-related additions? Or SVG with similar pointer enhancements.

Like DisplayPostscript? DisplayPostscript didn't specify the display hardware and user input layer, but typical implementations used X (or an alternative called the NetworkExtensibleWindowSystem) to provide it. SVG defines an image format; implementations need to work with a display abstraction layer like X in order to display SVG graphics.

Typical modern graphics systems not only separate networking from low-level graphics handling, they also separate low-level graphics handling -- bitmaps and accelerated graphics primitives -- from high-level graphics handling like widgets and window borders and image formats.

Doesn't that depend on the hardware? Why define a low-level interface if the hardware (graphics card) already has a low-level interface? The medium-level interface could specify vectors, for example, and the graphics card takes those vectors and converts them into bit-maps etc. I agree sometimes we may want an emulator, but it typically wouldn't be used for production.

Graphics card device drivers are built to specified standards. For Windows, that standard is DirectX. For UNIX and UNIX-like platforms, that standard is X. X (and DirectX) also provide low-level mechanisms common to all graphics displays that would be duplicated effort to include in each vendors' drivers.

Why not mirror Direct-X then on UNIX? You then have one standard instead of two. Or do people fear Microsoft will monkey with the standards in sinister ways?

Or why not mirror X on Windows? Why have Java and C#? Why have OS/X and Windows and Linux? Why have Android and IOS? Why have Crest and Aquafresh? Ford and Chevy; BMW and Volkswagen? Why are there multiple, competing, otherwise-equivalent anythings?

Note that X pre-dated DirectX, so I'm sure there was a hearty dose of Microsoft's usual NotInventedHere attitude.

Two wrongs don't make a right. And, some are looking to replace X, per ShouldXwindowsBeReplaced. Now's the chance to merge standards.

That's one wrong, not two, and replacing X with DirectX is infeasible would require replacing all the higher level infrastructure that depends on it. The X alternatives are all X-compatible.

Ah, so backward compatibility is a key goal. The replacements are then dialects of X, not outright replacements for X, if they fit an existing X interface.

[Presumably Y would be better than X. Anything X can do Y can do better. Emulation, at least, of X should be a design goal for Y. Backward compatibility is essential because X is pervasive. -- ChaunceyGardiner]

Replacements for X aren't "X" any more than (say) ReactOs -- a replacement for Windows 2K -- is Windows. Replacements for X do need to provide equivalent APIs to X's xlib and XCB libraries in order to maintain compatibility with X.

[Furious agreement]

CategoryXwindow CategoryDiscussion