Slashdot Mirror
Gnome 2.0 Beta 2 Released
plastercast writes: "Following the release of GTK2, the second beta of gnome 2.0 is available. There are also release notes here. From Gnotices: 'The GNOME 2.0 Desktop is a greatly improved user environment for existing GNOME applications. Enhancements include anti-aliased text and first class internationalisation support, new accessibility features for disabled users, and many improvements throughout GNOME's highly regarded user interface.'"
For those of you who aren't too keen on manually downloading all the individual packages and their dependencies, you may wish to try garnome (http://www.gnome.org/~jdub/garnome/).
It behaves a bit like the BSD ports tree as it'll download and install all the necessary packages. Even better, it'll install them in an out-of-the-way place so you can keep running gnome1.2!
Cheers Koz
the GNOME 2.0 Desktop is a greatly improved user environment for existing GNOME applications. Enhancements include anti-aliased text and first class internationalisation support, new accessibility features for disabled users, and many improvements throughout GNOME's highly regarded user interface.
:-)
Thanks for that info, it's not like we didn't read exactly that same blurb when beta 1 was released...
I bastun bor vi allihopa = we all live in the sauna (it's swedish)
Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
"I bastun bor vi allihopa = we all live in the sauna (it's swedish)"
Damn. You mean it's not "I'm cuckoo for cocoa puffs"?
All my hopes for this release are dashed.
Let's try not to let fact interfere with our speculation here, OK?
kcalc has the biggest footprint I've ever seen for a calculator
I have a suspicion this is to do with the C++ linker problem. In a nutshell, GCC"s handling of relocating libraries when they address collide sucks. It's slow. Really slow. The KDE team have been attempting to get over this by creating one process that loads most of the libraries - kdeinit, then forking the process to be the individual applications. The long and the short of this is the libraries remain loaded at the same address, don't have to reload and relocate, and all the processes can share the same code pages since they're copy on write.
Don't worry, they know it's a hack too.
There's a lot of work going into making it such that the GCC linker can build libraries to different default virtual memory addresses, hence stopping the loader from having to relocate libraries. When this happens the individual distros can be built with non colliding libraries, the kdeinit hack can go away and all will be at peace in KDE land. Personally, I'd delay 3.0 until the situation is sorted, but it's not my project.
Dave
I write a blog now, you should be afraid.
Everybody here had better learn to admit this is a problem.
The solution should also be looked at, and it is a killer: get rid of the "window manager". Most people seem to think this means that the window manager must be built into X, like Windows. But that only eliminates 1/2 the slow communication, and has the unfortunate effect of completely freezing window management design, which is a problem Windows is having relative to Linux right now (read the above comments!)
What I mean is "window managment" (meaning the positioning, decoration, moving, resizing, etc) of windows, should be part of the toolkit. The window border is no different than a button or anything elss. All sane people (there are some exceptions here) know that the drawing of the button should be up to the appliation or the shared libraries it decides to load, so why not the window borders?
But all the window borders will look different! Yes, they will. That is because it is impossible to have "consistency" and at the same time have "innovation". Think about it. And all those people who worry about "consistent user interface" should go and talk to some real users and they will find out that "consistency" is way overrated. Why aren't games "consistent"? Because they want to advance the state of the art. And I'm sure somebody will say "hey I was confused by the inconsistent Linux GUI", but think about it: what you really were confused by was two different interfaces, one a "stupid" design and one a (possibly) "smart" design. You were not confused by the inconsistency, you were confused because one of the interfaces was stupid. Also, look at the toolkits, with no requirements that they share code, they are pretty damn consistent, because they copy the working ideas from each other! If X had envorced "consistency" we would all be using the Athena widget set right now and trying to brag to Windows users that we can swap white and black in our preferences.
When we get rid of the window manager you will probably see some real innovation, like windows without borders (you move/raise them by grabbing any inactive area), and intellegent window stacking and ordering by programs that know exactly what window is important right now.
There will have to be a "task manager" (go ahead and take the Windows term, it won't bite). It would be like the "panel" in Gnome and programs would indicate they are running and respond to messages saying "appear" and "disappear" (or they can ignore the messages just to cause trouble, but it should be allowed).
Ok enough ranting on Slashdot.