Slashdot Mirror
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.
We can't replace Xfree! If we did, what new scapegoat out there would we blame for performance bloat?
"I like to wear big boy pants."
Anyway, all technical issues aside, X is an accepted standard that works across every UNIX platform, VMS, Windows, Mac, RiscOS, BeOS, Java, you name it. There is no practical reason to replace it; it does what it's supposed to do, and it does it well, and if there's something you don't like about it, it's extensible. IF for some bizarre reason it was felt that the protocol should be scrapped in favour of a new one, it should be X12, and it should be developed with the expertise and experience in the X crowd, not by random idiots who want alpha channels as a top priority! Furthermore, anyone who knows anything about the X protocol knows that it inherently supports a server supporting multiple versions of X simultaneously. So migration to X12 would be relatively simple, you would start with X servers and libraries supporting both X11 and X12 and move over. Whereas if some dumbasses decided to switch to Berlin we'd end up with fragmented, incompatible stuff and redundant work.
Bah.
Everytime X is mentioned, the UNIX grognards come out of the woodwork. All through the halls of
Compatibility: If I cared all that much about compatibility, I'd still be using Windows. 'Nuff said.
Network transparency: This is a half-decent point. However, Berlin does network transparency as well, so it is a moot point anyway. The truth is, other windowing systems do network transparency, and some better than X. If you don't believe me, read the docs on QNet and QNX's Photon. Whoa, somebody actualy DID come up with something better than X!
Maturity: I don't know how to explain this to the grognards. Let me put it this way. I love my grandparents. I want to learn from my grandparent's vast life-experience. However, there is no way in hell I'd be caught dead dressing like them. Even with a cap on backwards, a tweed coat is a tweed coat. The same thing holds true for software. 30 year old software, just like 30 year old people (no offense to those of you that far over the hill
Flexibility: Flexibility is over-rated. No, its true. X had to make some tough design decisions, and it chose to make things more flexibile rather than better. While a certain amount of flexibility is necessary, software should be designed with two goals in mind: Providing the absolute best experience for the next ten years (a generation in software-time) and providing some sort of migration path to the next level. While X, due to its flexible nature, has survived the last decade and a half, it is not, in its current form, able to keep up with its younger competitors.
A deep unwavering belief is a sure sign you're missing something...
Perhaps you missed the fact that Berlin is a Vector-based GUI. You know, like Aqua? I don't think there are any other GUI's out there with that capability(besides proprietary Apple one of course) and you certainly won't find any vector-based rendering extensions for X.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
Information on Fitts' Law: http://www.asktog.com/columns/022DesignedToGiveFit ts.html
Prevent email address forgery. Publish SPF records for y
Exactly, when I read the part about Berlin enforcing MVC I knew that there was no way that Berlin was ever going to take off.
X is here today, it works, it is improving, and it allows you to write your application however you want (even if it is the wrong way to approach the problem). Besides, the biggest problem with X is the fact that it is too low level to really promote code reuse, but both KDE and Gnome are frantically at work trying to fix this. Honestly, what new GUIfied software being written today for Linux doesn't rely on either the KDE or Gnome libraries for much of the heavy lifting?
If Berlin + GGI would have been available when X was still crusty and before KDE and Gnome existed then possibly it might have generated a following, especially if it would have included a legacy X compatibility so that I could still run all my X applications (there is no way I am using a desktop that doesn't include Emacs).
As my grandmother always says, "If wishes were horses then beggars would ride." The reality is quite different.
The Berlin folks are welcome to prove me wrong though. Competition is always good. And it's their time and effort.
"If They Only Opened Be" (to the tune of "If I Only Had a Brain")
I'd move my windows rapid, and they'd redraw not vapid,
They'd move responsively
I'd get such vast improvement In my mouse's pointer movement
If they only opened Be
My afternoons spent quaking, While simulatenously making
Illegal Mp3's
In multimedia heaven, Not in hell, like X11
If they only opened Be
Oh I, Linux guy, Would thrown my redhat CD in the trash,
If Jean-Louis would GPL the code, I'd ditch Linux--in a flash
No more time I would spend waiting, For massive screen updating
When launching apps concurrently
We'd all be very happy, With an OS far less crappy
If they only opened Be.
> * It seamlessly allows local and remotely-running
> programs to work together on a display
As does Berlin, Berlin does even better than X.
> * It is flexible enough to allow programs to fully
> determine how it is to behave on lots of things
Berlin does, too. But it strongly encourages to use the common facilities.
Here, less freedom for the app developer means more freedom for the user.
Think GTK Themes, just with much more configurability. The user can easily replace a widgetset implementation, and it will apply to all apps, because the API for the widgetsets is standardized.
Have you checked out Berlin's design? It is very powerful and flexible.
BTW: If you "fix" X, it's not the standard X anymore. You "enhanced".
Dammit, X has supported non-rectangular shaped windows since 1986, but try opening a round window in either KDE or Gnome, and what happens?
X has a few deficiencies in the multimedia area. These can be fixed. It's got to take less work to fix them than to replace X. Meantime, creating a new competing windowing layer is not going to unify the Linux desktop - Linux is not like that. Many people will stick to X anyway, some because they use programs which were written for it, some because they appreciate it's qualities, some (not many!) because they're too conservative to change. So what you'll get is more diversity, not less.
Not of course that diversity is bad. Diversity is good. And one of these days there will be a competing windowing layer that is better than X (if windows don't just become irrelevent before then). But if you think that X is bad, you're the wrong person to write a windowing layer, because you fundamentally don't understand the problems.
I'm old enough to remember when discussions on Slashdot were well informed.
X is great if you define great as a GUI protocol for running applications over a network. Unfortunately, that's not how applications are run today. I have my OWN processor, thank you very much, and I don't need to run Mozilla off of a honkin' big Solaris server. It's nice to be ABLE to, and sure, that flexibility is an advantage. Unfortunately, flexibility also has drawbacks, because you can't optimize for the specific cases. How fast do you think Direct3D would run over a network? The whole point of accelerator video cards is REDUCING the bottleneck between CPU/RAM/video. If X is going to survive, it doesn't necessarily have to drop the networked-application functionality, but it's sure as hell going to have to implement a "I know I'm running as both client as server, let me optimize" mode.
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.
Yup. X is a brilliant protocol for remote display. It's just a goddamn awful protocol for local display. Just because something is well well designed does not make it appropriate for the given task.
Not possible, X's primatives are simply too fine grained.
I look forward to using a gui that runs directly onto an accelerated local framebuffer, with an X server running on that. The network abstraction should run ontop of the gui. Not vice versa.
I've been following the Berlin project for a few years and I've had the opportunity to look through the source and even compile it on a few occasions. It saddens me to say that the development of Berlin is very slow and is verging on stagnant. It is the most advanced X alternative out there, but I'm afraid that it's not getting the attention that it deserves from developers. Perhaps dropping their ties with Python and implementing a more common C++/C api would assist in the acceptance of Berlin as an X replacement.
Okay, I'll accept that it allows you to do that (that's pretty much the whole point of X, really). But I wouldn't exactly call it "seamless". Between configuring
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
Sorry, this is just about the most annoying thing about X for most end-users, and there is always somebody who jumps up trying to defend it. I don't want every program to use a different widget set. I do want my programs to be able to support basic cut-and-paste. I want good support for scalable fonts. 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.
Having a general extension mechanism is a good thing. Needing to use it to provide basic functionality isn't such a good thing.
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.
I think Berlin has missed the boat. X11 has caught up, and better implementations of Berlin's ideas already exist. This is not the time anymore to loose another C++/CORBA thing on the world.
The frontiers in toolkits is elsewhere anyway. If you want to play around with a powerful, extensible toolkit, spend some time digging into Squeak. It's a research system and on the surface, it looks like a pretty unappealing and cumbersome system with a bunch of oddly colored windows. The documentation is so-so (take a look at the Wiki, it contains some tutorials). But Squeak and its toolkit, Morphic, are also extremely powerful, a window system in which everything is open to inspection and modification, in which everything can be made to interact with everything else, and in which there is a huge number of tools, browsers, and development tools. The whole thing can run on a plain frame buffer (it also runs fine under X11, Windows, or MacOS), and everything is built in Smalltalk.
- 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.
-- Erich
Slashdot reader since 1997