Berlin Project Lead Holds Forth

infodragon writes: "Here is a good interview with the project lead of Berlin. It is very informative and interesting, they talk about technologies such as gtk+, bonobo, corba ... If Berlin takes off it looks like X-Windows may have a competitor." That project head is Stefan Seefeld, and Seefeld gives good answers to questions like whether GNOME can or will be ported to Berlin, and how Berlin can hope to win converts from the millions of Xf86 users.

Comments

What Berlin needs to do

[spitzak]

I have followed this for years, in the hope that something reasonable will replace X. However I don't see the Berlin people really trying to produce what is needed, nor do I see anybody else doing so.

First, we do not need another toolkit. We need an environment that makes it easy to write toolkits. If we have this, GTK and Qt will be ported quite quickly, and maybe new toolkits simple enough to be programmed by mere mortals will appear.Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows", but conversely you should be able to easily (ie with no setup before the drawing function) do full PostScript and OpenGL graphics into these, and anti-aliased fonts, full UTF-8 formatting of text, and high speed placing of images with arbitrary linear transformations from user memory onto the screen.

(The problem with Berlin and the other projects like it is that is is really trivial to write a toolkit compared to writing what powerful antialiased graphics or asynchronous communication interfaces, and writing toolkits appeals to the programmer's desire to control how others use his/her system, so the programmers get diverted to this useless bloat that actually makes their stuff less likely to be used.)

Berlin has to have an Xlib emulation library so that X11 programs (and remote X clients) can display on the Berlin server. Fortunately this is easier than it used to be because the emulation library only has to pretend that a TrueColor visual exists (a few years ago emulating an 8-bit colormap was mandatory to get some of the awful X clients to work, but these have disappeared). This emulation is absolutely necessary so that people can migrate to Berlin. There is no need to be able to run X window managers.

Conversely, Berlin programs must work on X11. The graphics can be lousy, very slow, and plenty of functionality can be missing (don't crash, but leave blanks in the output). This requires an implementation of the Berlin interface that works atop Xlib. Without this people will not write new applications for Berlin.

Finally Berlin must be easy to program. It should be absolutely clear to someone without a PHD exactly what you do to create a window and draw into it, and to get events, by reading the manual in sequential order. The set of calls should be reduced as much as possible, there should be as few arguments as possible, and none of the arguments should be structures or pointers to structures. Use a static graphics state like OpenGL. And there should not be gratuitous objects, colors are identified by rgb numbers, not "color objects", fonts are identified by names, not "font objects", etc. Use integer ID's for the canvases.

The library has to be C rather than C++ or any other language to make the Gnome/GTK people happy.

Linux's GUI problems

[Ukab the Great]

1. Many (not all, but many) Linux people do not understand the desktop, nor do they understand end-users, nor do they understand fundamental GUI design concepts. Go to a LUG meeting and ask everyone who knows what "Fitts' Law" is to raise their hands. Few hands if any will be raised. The linux community is approaching the concept of linux on the desktop from a server-based perspective, and this will not work. Mention killing X and immediately your get arguments of how great X's network transparency is. "Linux on the desktop" will not work. A desktop that "just happens to use Linux" will. A successful linux UI will be one that will be designed as if the command line never existed.

2. Standards have to be good standards. They have to be well chosen standards that are done for sound reasons that are based on fundamental usability principles. We're not talking about "you say tomato, I say to-ma-toe" issues, we're talking about stuff that's been proving by the cold, hard science of cognitive psychology and usability labs. As mentioned in #1, most of the people involved with linux don't understand basic usability principles, so they copy others who they think do understand these principles. Unfortunately, the people that they copy are just as much in the dark about designing good UI as they are. I'm talking about Microsoft. Microsoft started off on a bad note in the initial design of windows when they intentionally violated many proven UI design principles just to avoid Apple look-and-feel lawsuits. Throughout the last ten years of computing history, the only consistency microsoft GUI's have had is the consistency with which they have been cluttered, confusing, unintuitive, inefficient, and inconsistent. Everything from cluttering UI widgets with zillions of underline accelerators to MDI windows within windows to adaptive menus that move around on the user have made Windows the textbook case for bad UI design. I've heard myths of micrsoft usability labs in the Himalayas that have large staffs of highly trained Yeti's with PhD's in design and cognitive psychology. Apparently Microsoft's own programmers have never heard of such myths. Check out the Interface Hall of Shame website. Microsoft is by far the most frequente inductee. I guarantee you that any standards (including any set by the GNOME Foundation) will be nothing more than "Let's go copy Windows". I'm not very optimistic, which is why I'm forking GNOME. The one thing that linux has going for it in the standards department is that people who understand how to craft good standards have the code to do so.

Don't start over, just help X

[Erich]

X is NOT bad. It's very well-designed.

• It seamlessly allows local and remotely-running programs to work together on a display
• It is flexible enough to allow programs to fully determine how it is to behave on lots of things -- X does not force you into a specific widget set or window decoration method, window placement behaviour, or anything else
• It is flexible enough to have extensions to help with some things. Lately we have seen extensions to add Anti-Aliased fonts and to aid in 3D display and moving picture display.

Many of the old ``problems'' of X, such as no anti-aliased fonts and poor support for moving pictures and 3D, are being addressed within the existing framework of X. This is because X is great, it allows for this sort of advancement while still having compatability.

If you want to make your windowing stuff faster, if it's X's fault you can almost always fix it. But I think that we can do a lot from within the framework of X. I see a future where X actually has most of the stuff running inside the video card, and programs on the local machine sending updates to it, similar to the way in which programs update remote displays over a network. Without the framework of a flexibile windowing architecture this is impossible, but with flexibility it is within reason.

Please don't get rid of the good to go with the new. Don't just sit around and bash X, either. 'Cause X kicks butt. If you have a problem with X, fix it. Don't just whine.