Slashdot Mirror
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.
From what I can gather from reading the comments to the Linux Today article, the main things that have changed and the underlying libraries, nothing that would really change the look. So apparently a screenshot of this wouldn't really look any different from a screenshot of gnome 1.x.
Guess again. :-)
http://www.gnome.org/mirrors/ftpmirrors.php3
ftp://ftp.twoguys.org/GNOMEg /pub/GNOME/s es/gnome-2.0-lib-alpha1/
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.or
ftp://ftp.sunet.se/pub/X11/GNOME/pre-gnome2/relea
Go fish! :-)
Money for nothing, pix for free
It will come out on this friday:
- 2.2.2-release-plan.html
Date: Tue, 2 Oct 2001 17:22:16 +0200
From: Dirk Mueller
I delay alpha1 release until Friday to give us more time to fix and verify the recent regressions in KIO and khtml.
Also, there will be a kde 2.2.2 release soon, check http://developer.kde.org/development-versions/kde
Well, actually, KDE 3 alphas have not come out yet. The first one is due Friday, afaik. However, most of the rest of your comment is correct, I think. KDE 3 will probably come out sooner than GNOME 2.0 will too (KDE 3 alpha1 is a usable as a end-user desktop, while GNOME alpha1 seems to be a technology preview). So, according the the latest KDE 3 release timeline, it should come out in February.
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"
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.
Unfortunately, too many people who are ignorant about the issues are jumping on the C++ bandwagon.
I've been using C++ since 1990! I helped port g++ v1.35 to the Atari Mega 4ST. I've followed the language evolution all the way till now. Many of my projects use C++.
Yet, many C++ projects that I see being done by other people are horribly misguided and doomed to failure. There are very good reasons to want to stick to C code!!!
Trolltech's QT lib is NOT one of them. For the most part, QT is ok.
--jeff
ipv6 is my vpn
You know you can use GIMP under KDE, and KDE apps under Gnome, right? It's amazing how many people don't. Yes, you need to install both sets of libraries. No, it isn't the end of the world to do so.
Your right to not believe: Americans United for Separation of Church and
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
I said no... but I missed and it came out yes.
Sigh... I just spent 10 minutes typing in my response and then slashdot/IE killed my post.
I'll do the short version.
#1 Most people who say they are C++ programmers actually are not properly educated in it, and have no or very little understanding of exception safety, const correctness, mutable, co-variant return types.
#2 Code re-use is a fallacy. Very often projects are factored way too much in the name of code reuse. What is important is GOOD DESIGN MEETING THE SPECIFICATIONS. Code re-use may or may not be part of that. When it is, it is a major thing. It does not come automatically because you typed 'class' instead of 'struct'.
#3 The C++ Fragile Base Class Problem. http://2f.ru/holy-wars/fbc.html
#4 C++ is a multi-paradigm language. Not only procedural, not only pseudo-OO, but generic programming too. Quite often the generic solution is the best solution under C++. I've never actually physically met more than two people who understood generic programming. sigh.
#5 Many C++ compilers just plain suck. You have to code for the lowest common denominator for the platforms that you are interested in.
#6 There is no (and can be no) standard binary API for C++ libraries. Other languages have a much harder time calling C++ libs than C libs.
--jeff
ipv6 is my vpn