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.
users.
That could be put on half or more of the stuff on my box.
Best Slashdot Co
I know a couple of widgets from gtk1.2 is deprecated, CList is one of them. But will gnome 2 also include gtk1.2 or only gtk2.0.
And, does deprecated in the gtk2.0 case mean "not there" or "could disapear in the future"?
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
Anyone know if there's intent to implement some kind of simplified IPC? Similar to DCOP? I'm a CORBA developer and even I think that CORBA presents a fair ammount of work to perform some relatively simple things.
BTW: Great Job on the multilingual!, as someone who likes to have his desktop in traditional chinese this is a big deal for me.
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.
I'm pretty sure that gdk-pixbuf should be moved to stable. A lot of programs have been using it for quite some time.
My only political goal is to see to it that no political party achieves its goals.
By "most productive", did you mean "only"?
I promise you that those of us who refuse to use C++ do not do so out of ignorance. Quite the opposite, in fact: I don't use C++ precisely because I know more about it than you.
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
Nautilus shouldn't suck
... give me a break people, the only ones damaging BOTH desktops are the people that are supposed to be pushing for open standards and competion! Don't believe me, then read the crap in this thread.
The latest Nautilus builds I have tried with the merges from the Red Hat guys have been AWESOME. Still needs some work, but it has come a long way towards becoming everyday usable.
Work with KDE instead of against it - Why all the hate between these 2 groups?
Why do people say this? I don't get it. I don't see Gnome developers trolling KDE, I don't see KDE developers trolling GNOME. What do I see? Users trolling for their preferred choice. Its not like KDE guys are making KDE apps not work in GNOME or vise versa.
Everyone talks about this huge war and how only one can survive
Well, there is still one important issue left with KDE. The Qt library is released under a GPL license as opposed to the LGPL license for GTK+. This prohibits developers of commercial (non-GPL) applications from using the Qt library and therefore developing for KDE without paying royalties to TrollTech.
This might not be an issue for the OpenSource community, but it sure is an issue for all the companies that have to make a living. This is why companies like SUN, HP etc. has chosen GNOME as their next desktop.
Just my two bits "01" - It's a fact, like it or not.
While it's true that hardware and software are essentially the same thing (a favorite rant of mine, BTW), it's not true that hardware is necessarily "better" than software, even in the speed department.
If we look at this proposal from a perspective of practicality, it clearly falls down. Hardware is incredibly difficult to debug and change. That is the beauty of software. The fact that complex computer architectures are implemented in terms of software (microcode) only points to this flexibility.
To address your speed claims, I point you to HP's Dynamo project. Dynamo is a dynamic translator for PA-RISC binaries. It is a software system that translates PA-RISC instructions to PA-RISC instructions at run-time. That doesn't seem to make much sense until you realize that the translation includes optimizations that can only be done at run-time. Binaries actually run faster under Dynamo than in native execution mode. By putting in a layer of software, HP was able to increase system speed.
One cannot do this in hardware because metal and silicon is fixed and FPGA's are too slow. Yes, people are researching reconfigurabler hardware, but that is for very specialized applications like DSP's, applications that are already used to boost graphics performance today.
A final observation: hardware gets much of its speed from parallelism. A ripple-carry adder runs much more slowly than a carry-lookahead adder. While certainly running at the speed of light (yeah, yeah, give or take) helps, parallelism (pipelining, O-O-O execution) is what got us the machine speeds we see today.
Parallelism is really, really hard to extract at the instruction level. Theoretically, it's there, but damned if I know how to get at it. Certainly lots of graphics routines have loads of parallelism. But guess what? We already have hardware to exploit it!
Modern GUI's really don't need to be much faster than they are now. We all like high framerates in our pretty games, but those are very specific applications. In fact, good hardware solutions already exist for them. I don't see RAM consumption as a problem, considering that X runs just fine on the iPAQ with room to spare. I have no idea what software you are running, but the CPU usage of graphics code is not even close to the largest consumer of cycles on my machine.
We already have good graphics hardware. Moving the X/GNOME/KDE control into hardware would gain almost nothing.
X-Windows: ...A mistake carried out to perfection. X-Windows: ...Dissatisfaction guaranteed. X-Windows: ...Don't get frustrated without it. X-Windows: ...Even your dog won't like it. X-Windows: ...Flaky and built to stay that way. X-Windows: ...Complex nonsolutions to simple nonproblems. X-Windows: ...Flawed beyond belief. X-Windows: ...Form follows malfunction. X-Windows: ...Garbage at your fingertips. X-Windows: ...Ignorance is our most important resource. X-Windows: ...It could be worse, but it'll take time. X-Windows: ...It could happen to you. X-Windows: ...Japan's secret weapon. X-Windows: ...Let it get in *your* way. X-Windows: ...Live the nightmare. X-Windows: ...More than enough rope. X-Windows: ...Never had it, never will. X-Windows: ...No hardware is safe. X-Windows: ...Power tools for power fools. X-Windows: ...Putting new limits on productivity. X-Windows: ...Simplicity made complex. X-Windows: ...The cutting edge of obsolescence. X-Windows: ...The art of incompetence. X-Windows: ...The defacto substandard. X-Windows: ...The first fully modular software disaster. X-Windows: ...The joke that kills. X-Windows: ...The problem for your problem. X-Windows: ...There's got to be a better way. X-Windows: ...Warn your friends about it. X-Windows: ...You'd better sit down. X-Windows: ...You'll envy the dead.
Copied from this page.main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Maybe you should try reading the fine manual. You can *very* easily disable this behavior.
First:
Preferences --> Advanced
Then:
Preferences --> Windows & Desktop
and uncheck "Use Nautilus to draw the desktop"
Now, that wasn't so hard, was it? Don't knock a great piece of software (even though I rarely use filemanagers) just because you didn't read the docs.
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
- How many cool toys you have
- How slick the thing looks
- What language you use (those OO C is a pain in the ass to code in)
- How many graphics buzzwords like AA or DRI you support
- How little memory you use
- How technically elegant you make it
Real progress can be defined as whether the secretary, farmer, mechanic, CEO, or whoever else who isn't a card-carrying geek was able to be more productive and feel better about using than computer than they were with the last version. Anyone,GNOME, KDE, or otherwise, who does not understand this does not understand the desktop. If you do not understand the desktop, you will at best produce a successful user-hostile abomination such as Microsoft did and survive entirely by the politics of corporate IT or at worst get your butt slammed across the entire computing industry.