Gnome 2.9.4 Dev Release Available
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Link choice makes no sense.
anyone know what the big stuff is gonna be for 2.10?
That’s really confusing, shouldn’t it be gnome 3.0? 2.1 came out a looong time ago
2.1 != 2.10
2.1 is after 2.0, 2.10 is after 2.9 (or 2.8 if you only consider stable releases)
It’s complexity gets to me. This is an old argument, but it goes beyond the number of packages. The thing that really bothers me are the hard-coded paths in *-config scripts and other files in library directories. I’m not sure if these are really specific to GNOME, but it bugs me that “Microsoftish” things are appearing. The hard-coded paths prevent a person from easily relocating software, which is a huge PITA.
Is it that hard to press the link to the NEWS files?
I’m wondering when Metacity will finally use that patch (can’t remember the url anymore) that enables it to use PNG’s to define translucent pixels when the X.Org server with Composite extension is used.
That would allow for some sweet Metacity themes and more importantly, it would allow them to look much more polished (like on OS X, where everything seems to be nicely AA-ed).
One of the trade-offs in developing a desktop environment that is intuitive and integrated is that these animals are inherently complex. The greater the abstraction from rectangles on the virtual screen, the greater the complexity of the system. I assure you, the Quartz/Cocoa/Aqua stack is every bit as complex as Xorg/GTK/GNOME. I think at some point we need to make a decision to either accept that the user can no longer fully conceptualize the inner workings of the modern desktop environment, or run something simpler (fluxbox, fvwm, etc.)
In other news, the few compositing managers that do work with Xorg 6.8.x reveal that much work needs to be done before the Composite extension is feasible. Enabling compositing on my Athlon XP 2500+ with 1GB or RAM makes the system plain unusable. I like eye candy as much as anyone, but not if it sucks the life out of a performance/mainstream hardware configuration. Most of this sluggishness arises from X11’s client-side rendering model. To get a sense for why X is never going to do translucency (well), read Mark Thomas’ research paper on his Y-Windows project.
You need to add something like this to your xorg.conf(in device section) if you are on nvidia and want decent performance:
Option “RenderAccel” “true”
No noticable performance hit with this option on a 2100+, GF4 128MB.
I have enabled compositing support under Gnome literally just before reading this article. Using Nvidia’s drivers I just turned on 2D acceleration using the RenderAccel option, and started xcompmgr up.
It’s incredibly smooth for me – definately smooth enough that it’s going to stay enabled, even though there are a few bugs floating around, such as windows maximising to full screen, rather than full screen – panels.
If you restart the panel after you’ve started xcompmgr, windows will no longer be able to cover the panels.
A reworked nautilus with a few longstanding annoyances fixed.
A reworked panel with a places menu, and ubuntu style order for the menus. The potential inclusion of Soundjuicer as the default cd player. A much improved gstreamer…
Thats just off the top of my head. I don’t know if there is a simple ‘whats new’ file at this point.
The panels could certainly use more polish, I’ve this this for about, well, ever…
I agree. The gnome panel is a really unapealing aspect of the gnome desktop. I mean the OSX dock has been out for some time, and though I’m not interested in a knock-off (gdesklets and e17 included) I’d sure like it if the gnome people gave us *some* innovation and eye-candy. How bout an option to have true transparency with xorg? How bout making phony transparency look decent (instead of blocks of ugly around applets). How bout making autohide work decently. How bout giving some option to remove the ugly handles from the edges of a non-expanded panel (yes I’ve filed bug reports). How bout… eh after reading my own rant, I’m guessing someone’s just going to have to create a better replacement, maybe I’ll learn to code (now if only there was a current gnome programming book in print).
Hate to sound whiney, but why is it that *cough* somebody never, ever seems to link to the NEWS file?
I’m sure enough people have commented on this for it to become obvious. Anyway, it’s all cool, links below:
Annoucement:
http://mail.gnome.org/archives/devel-announce-list/2005-January/msg…
NEWS:
http://ftp.gnome.org/pub/GNOME/platform/2.9/2.9.4/NEWS
http://ftp.gnome.org/pub/GNOME/desktop/2.9/2.9.4/NEWS
http://ftp.gnome.org/pub/GNOME/bindings/2.9/2.9.4/NEWS
The servers seem to be suffering from the slashnews effect as I type, so go easy on them =).
Can’t wait till this hits Hoary Hedgehog – what would be even better, though, would be if packages were available for Slackware (which, IMHO, I like over Ubuntu)…one can always hope *grin*.
Bye,
Victor
ryanpg,
The gnome-panel may be ripe for an overhaul, but not in the name of “eye-candy” and most certainly not at the expense of functionality. Everyone and their grandmother know how unusable the OS X dock is. The OS X dock deserves an accolade spot in the usability hall of shame.
Your post is a classic example of why users think they know what’s best for them, when in reality they could buy a clue. Innovation for the sake of innovation is silly. Innovation should be a by-product of trying to make software more egonormic, efficient, usable and productive.
http://www.asktog.com/columns/044top10docksucks.html
Why doesn’t compositing use opengl for acceleration? My intel 845G has >400 FPS in glxgears and i thinks it’s fast enough for compositing. Does anyone know if anyone is working on it?
It uses hardware acceleration, but it depends on your driver. And your driver doesn’t support hardware acceleration…
Xcomposite currently uses the X Acceleration Architecture as it’s back end by default. The nvidia drivers implement their own acceleration mechanism themselves.
XAA is slow at translucency because it’s not feature-complete at the moment.
When XAA gets improved, so will Xcomposite.
Summary of *interesting* news regarding GNOME-related projects http://gnomedesktop.org/node/2117