Time for X12? [LWN.net]

Time for X12?

Posted Apr 3, 2003 21:47 UTC (Thu) by spitzak (guest, #4593)
In reply to: Time for X12? by jamesh
Parent article: A discussion with Keith Packard

You don't have to "break compatability". What is needed (and is missing
from X right now) is a clear decision that the new interface is the
STANDARD, not an "extension", and THE OLD INTERFACE SHOULD BE EMULATED
ATOP IT.

For instance, multiple visuals and pseudo color are easily emulated
without breaking any applications. Any applications that expect a
"visual" must list the available ones, and they will be told there is
only one (a 32-bit rgba truecolor visual). And a vast chunk of horrid
code can be DELETED from X.

The problem with Xft and so on is that it is an "extension" only. They
should have written things so ALL applications got the same set of
anti-aliased fonts and all ran through the same new code at the bottom.
This could be done by changing Xlib to use the Xft interface. The legacy
system would not "fall into disuse", it would be DELETED IMMEDIATELY,
without breaking any existing programs.

As I have said several times, the X developers should be ASHAMED of the
fact that MicroSoft managed to change their GDI32 interface to use
anti-aliased fonts in a way that all programs could use them without
being rewritten, yet they could not do the same feat.

(Log in to post comments)

Time for X12?

Posted Apr 4, 2003 13:54 UTC (Fri) by jamesh (subscriber, #1159) [Link]

If it didn't break backward compatibility, it wouldn't be X12. The fact that it is possible to build all the features people expect in a modern windowing system without breaking old apps is a _good_ thing.

There is nothing inherently bad about using X11 extensions -- you will probably find that all/almost all of the apps on your desktop are using at least one extension. They allow an application to query whether the X server supports a certain piece of functionality. If the extension is not available, the app can decide to either use some fallback code or simply die.

The extension mechanism is the reason that things like the RENDER extension to be added with minimal impact, and remove functionality that turned out not to be such a great idea (ever heard of the PEX, XIE or Zoid extensions? If not, that proves my point).

In your reply, you seem to have been mixing up interface and implementation quite often. As new functionality gets implemented in the X server, there is no reason why the implementation of the old interface has to stay around -- it could very well be reimplemented in terms of new code.

On the subject of fonts, it is true that the old core fonts API was inadequate which is why a new API needed to be developed. If the old API had been sufficient, then it probably _would_ have been updated (remember that the core X11 protocol is a fair bit older than GDI32). On the bright side, the font configuration portion of Xft (which is now in a separate library since Xft 2.0) is generic enough that it could be used to configure the selection of fonts available through the core protocol which would allow an administrator to configure the same set of fonts for both APIs.