Gnome 2.0 Alpha 1 Released

Dave H writes "The first pre-release of the GNOME 2 platform is now available! Find it at you can grab it from FTP.gnome.org It is of course a technology preview; note that it can't be installed alongside GNOME 1.x." There's some more information information posted on LinuxToday.

Comments

ftp mirrors

[richie2000]

you can grab it from FTP.gnome.org

Guess again. :-)

http://www.gnome.org/mirrors/ftpmirrors.php3

ftp://ftp.twoguys.org/GNOME
ftp://ftp3.sourceforge.net/pub/mirrors/gnome
ftp://ftp.rpmfind.net/linux/gnome.org/
ftp://ftp.sourceforge.net/pub/mirrors/gnome/
ftp://ftp.cse.buffalo.edu/pub/Gnome
ftp://ftp.yggdrasil.com/mirrors/site/ftp.gnome.org /pub/GNOME/
ftp://ftp.sunet.se/pub/X11/GNOME/pre-gnome2/releas es/gnome-2.0-lib-alpha1/

Go fish! :-)

Re:Backward compability.

[Havoc Pennington]

GTK 1.2 and GTK 2 can be installed simultaneously, I would expect all distributions to do that for the forseeable future.

Deprecated means "will disappear in some future version, when not many people are using it anymore"

Re:GNOME, a thought

[Havoc Pennington]

X is very simple, for a windowing system, it's not complex at all. Plus no one has to see that stuff,
it's always hidden behind toolkits.

X doesn't have a drag-and-drop system, so I don't see how ROX could use it. DND is built on top as a custom protocol (Xdnd) shared by GTK, Qt, etc.
I would guess that ROX just uses Xdnd, isn't it GTK-based?

Berlin is far more complex than X.

Porting GNOME/KDE to Berlin would be infeasible, but said infeasibility would have nothing to do with different CORBA implementations.

Most UNIX vendors do not reimplement X, they are basically using the open source implementation with some minor tweaks. The open source implementation (primarily maintained by XFree these days) is generally more robust than the proprietary ones.

Re:GNOME, a thought

[Panaflex]

I'm a newbie by standards around the X community, but alot of past work is devoted to old nasty things.. I've been lightly studying it for a few years, and have provided alpha ports for voodoo chips in the past.

X was written from a frame buffer perspective, and had accelleration hacked in over time, until Mark Vojkovich developed a standard for it(XAA, iirc). Attempts to go towards a rendering pipeline are embodied in the excellent work in Xrender.

The drivers are all fairly minimal bits of code.. most of them rely on other modules to initiate standard display setting, etc.

Alot of the "cruft" in X is related to the I18N sctick that got hacked into R5 I think. More cruft comes from PEX (The long-dead competing standard to OpenGL), the horrible toolkit helper implementation known at Xt, the keyboard and colormaps (scarry). The seldom used XPrint and Xnest servers as well.

More cruft comes in with several implementations of frame buffering code implementations (fb, cfb, cfb16, cfb24, cfb32, mfb) XAA kinof added a layer below these original "drivers."

Also, there is a huge amount of interface code from X to toolkits such at gtk/qt. This code is mostly hidden in the X11 libs. Do a stack trace when drawing a button in GTK with X11 debugging on.. it is truly horrid (13 deep to draw a clipped line), and doesn't show the server side of the mess.

Also, X has a very syncronous rectangle management core. The server keeps a list of all viewable rectangles and updates the whole list after every rectangle update. (Slow window movement, anyone?)

The biggest problem with X is simply the fact that toolkits have been religated to client apps, instead of being loadable into the X server.

Often times core X developers argue that this is dangerous, and even say that client side apps are faster and are fixed in their minds that X is the only way to go. A huge chunk of code goes for all the abstraction(known as mutilation by code in my book) and platform independance.

By no means should we throw away all that knowledge, but it should be second tier to providing native interfaces IMHO. Larger processor caches and faster asyncronous graphics chips somewhat nullify this argument these days, but the fact remains that X would be alot faster without it.

In fact you're starting to see X as simple a pixmap display device in the end. All the toolkits are basically just blasting pixmaps into the server, because X can't handle much of the advanced graphics now anyhow.

Yet sitting down to a windows box is proof positive that X is slow. I'd say that a good rewrite would do X a world of good. Let applications communicate in terms of toolkit messages (add widget tree instead of get gc, 8 drawlines, 3 fills, and get font, set font, get colormap, set colormap, draw text).

Of course this could be *maybe* be done with an X extension, but there are a few limitations of what X extensions can perform without going and adding more hacks into the X server.

All in all, X11 is a fine piece of work. The work done in the past 2 years is fantastic to say the least. All the linux companies and the freetype, mesa, and DRI developers really deserve a major pat on the back. I really enjoy the engineering talent and ingenuity displayed by the XFree team.

Cleaning up X, or rewriting it would be a major step in the right direction.

A funny thing about windows, is that they have the opposite problem. Applications are often times tied _too_ closly to the GDI, and often break between versions. No doubt, a few graphics intensive applications from win31 would break on win2k.

Pan