The first beta release of GNOME 2.6 is available for testing. Changelog, download location, gotchas.
GNOME 2.6-Beta1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
All these sources would be rpm’s so I could just build straight off them
… ah well, maybe it’ll catch on yet 
Or portage.
Or an apt repository (debs for Debian)
Looking at the above comments, it’s almost a pity there are so many different ways of packaging up source code for distributions, and in fact it is a bigger pity there isn’t a tool that could take the source and build all types of packages in one hit.
…to emerge this onto my Gentoo box 😉 Over the year or so, Gnome has become my favorite platform. I am very excited about what the future holds for this desktop. Bring it on!
The guys over at http://www.breakmygentoo.net/ are usually very quick with getting ebuilds of the latest and greatest stuff out. Check if out if you’d like to try the beta releases. I’m running 2.5.2 and it’s relatively stable.
“Looking at the above comments, it’s almost a pity there are so many different ways of packaging up source code for distributions, and in fact it is a bigger pity there isn’t a tool that could take the source and build all types of packages in one hit.”
“Looking at the above comments, it’s almost a pity there are so many different ways of packaging up source code for distributions, and in fact it is a bigger pity there isn’t a tool that could take the source and build all types of packages in one hit.”
Agree 100%
Linux/distro devs need to get focused on the real problems, not deny them and just do something more fun instead like now.
Sorry about that I hit the enter key on accident.
Anyway, I was going to say, I get your point but is that what we really want…one way to do anything. It’s not healthy in almost any subject matter that there be one solution or method to getting something done. Sure it makes it a little diffucult sometimes. But installing a new desktop environment is not exactly a task for your aunt or grandpa. It’s generally something best left for your distribution.
Outside of the software world we have many choices to make and differences to deal with daily:
Automatic or stick shift
english or metric
NTSC or PAL
Old style rotary or touch tone phones (I imagine at one time this was a big deal)
I know there are a ton of other examples all around us, they escape me at the moment. And yet we somehow manage to cope. Having the choice between a tarball, deb, rpm, or some other dodad is a good thing.
competing standards like NTSC/PAL, GSM/(that US phone system) exist due to political reasons, not to make anything better for the consumer!
Ex: The phone manufacturers need to develop diff handsets for the american market than the rest of the world.. wich means more expensive products! Oh and the consumer has to pay that cost, and cant use his/her phone when travelling to/from US.
“Having the choice between a tarball, deb, rpm, or some other dodad is a good thing.”
For who? and why? Sounds like another excuse to me.
…i was wondering when this would be announced. The first beta was due 2 weeks ago… i hope this doesn’t set them back too far, schedule-wise.
*fingers X’d for relatively bugfree beta test*
“For who? and why? Sounds like another excuse to me. ”
It promotes competition and invention. It’s also inescapable.
Anyway, I’m not trying to start a fight, it’s just the way I feel. Having multiple variations of a product or method often means that someone is dissatisfied somehow with the previous version.
If you need binary packages or portage scripts, then waiting a week or so should take care of you. Don’t expect beta releases of something as large as Gnome to come in all flavors of installs the day its released.
I mean, that really is common sense.
Oh, and as for GSM phones in the US: got mine last week. Works like a charm.
>> All these sources would be rpm’s so I could just build straight off them
… ah well, maybe it’ll catch on yet 
In a perfect world.. all of these new releases would be distributed as Autopackages… so everyone and their dog can install the software in a few minutes on every mainstream Linux distribution without building anything (unless the person would like that) and without waiting 2 days for the builds to be done.
Until then, life sucks.
I’m not too sure I would want to make beta software easy to install for non-developers, beta software is meant for bug testing & not for every day use.
“I’m not too sure I would want to make beta software easy to install for non-developers, beta software is meant for bug testing & not for every day use.”
And one can find very often packages of betas without even debugging symbols. This tells you what they are for.
I wasn’t saying that we should have ONE way to do a package, but a single tool that could generate all the different packages from source.
For example, I use gentoo, so I would like something that could possibly generate an ebuild.
Someone who uses Fedora/Suse would like an RPM.
So this tool could create my ebuild, create an RPM, create a DEB file, create a TGZ for slack.
Obviously this can’t be easy, otherwise it would be done already, but I’m sure there would be a way to do it if some of these dev’s put some thought into it, some of the other tools created are fantastic, so it can’t be impossible, just possibly annoying.
Extremely useful it would be though, and would save a lot of people a lot of work I’d say?
“Looking at the above comments, it’s almost a pity there are so many different ways of packaging up source code for distributions, and in fact it is a bigger pity there isn’t a tool that could take the source and build all types of packages in one hit.”
“Agree 100%
Linux/distro devs need to get focused on the real problems, not deny them and just do something more fun instead like now.”
What is your recommendation concerning the theological issues? The real grail, IMHO, is a license- and platform-agnostic tool.
Oh, and while dreaming in public, let’s integrate with versioning and design tools, as well.
“I wasn’t saying that we should have ONE way to do a package, but a single tool that could generate all the different packages from source. ”
How about Checkinstall? (http://asic-linux.com.mx/~izto/checkinstall/index.php)
> How about Checkinstall? (http://asic-linux.com.mx/~izto/checkinstall/index.php)
Happy entering the infos every time after you have untarred, configured and maked every package…
And it doesn’t support ebuilds BTW.
Something like this should be integrated in automake or something alike, so that you can do make deb/rpm/ebuild easily.
“Happy entering the infos every time after you have untarred, configured and maked every package… ”
Sure, it can be improved in some places (how about a nice gtk gui?), but it is a start. It’s a great tool if you want to restrict your package management to rpm (or deb).
> Sure, it can be improved in some places (how about a nice gtk gui?)
I think a gui would be counterproductive. It only adds more code to checkinstall but doesn’t solve any of the problems (manual building, manual info entering).
It’s a nice backend for self-built binary packages, but nothing more.
A standardized system like CPAN would be good, you’d just have to execute a script and you’d have an ebuild or a deb or have it installed with no pkg sys.
…such a tool exists for Windows 😕 The point is software packaging is hard and should be left to proper packagers. You can learn, and it is mostly done for you. Especially since most, if not all main GNOME packages come with spec files for creating rpms, and info to make debs.
Anyone has already installed it? Any screenshots?
Do we really need a new version with new features? I don’t know what u really want but I would prefer fixing bugs and improving performance than adding new features. When I first tried Linux about a year ago I thought everything was slow and performance sucked,If you outspeak about this you’ll be ranted and told to use a minimalistic window manager. I’m not willing to use a minimilistic WM just because KDE and Gnome are much bloated. Aslong as I run say Windows Xp with satisfying performance then I expect to find an equivalent alternative on Linux, not some bloated DE with so many features like KDE and another bloated DE with even less features.Don’t get me wrong here, but I thought if would be much better for the developers to just decide not to add any new features for a while and start optimizing their code and fixing bugs. Seems that the kernel guys and the KDE teams heard me and both kernel 2.6 and KDE 3.2 came out with an improved performance. I just hope that all the other projects just follow the path. Saying that cpu cycles and memory are getting cheaper and that programming time is more important doesn’t convince me. I hope that we get new versions of Gnome with better performance.
I think the problem with Gnome performance isn’t Gnome per-se, but Gtk2.x. Eugenia interviewed Havoc Pennington(I think that’s his name) and asked him about gtk+ slowness and he basically acted like he had never heard of it.
Huh? Usually when software developers for Gnome/KDE/Linux release new versions, it does include bug fixes. And they do try to increase performance, and yes, it will include new features. Why? Because many bug fixes aren’t just “buffer overrun” type bugs. Some bug fixes are non-HIG compliant items (in Gnome, for example), or it’s a bug, and by fixing the bug, the developer adds a new feature.
And of course, their is nothing wrong with adding new features. People act like features == bloat, and that’s it. I am sorry you felt that Windows XP is faster than Gnome or KDE. I felt quite the opposite (and still do).
“but I thought if would be much better for the developers to just decide not to add any new features for a while and start optimizing their code and fixing bugs. Seems that the kernel guys and the KDE teams heard me and both kernel 2.6 and KDE 3.2 came out with an improved performance.”
The big misconception is that if you release features, you aren’t fixing bugs or increasing performance. That’s a complete misunderstanding. Both KDE 3.2 and the kernel came out with new features, fixed many, many bugs, and in the end, tried to increased performance.
But it’s not like there is some magic “Performance Button” that you can press and suddenly, everything just runs faster.
“Do we really need a new version with new features? I don’t know what u really want but I would prefer fixing bugs and improving performance than adding new features.”
You get your wish, they do that EVERY release. They always fix bugs, and they always work to improve performance.
nuff said.
I wasn’t saying that we should have ONE way to do a package, but a single tool that could generate all the different packages from source.
For example, I use gentoo, so I would like something that could possibly generate an ebuild.
Someone who uses Fedora/Suse would like an RPM.
Well, packages are usually just ./confugre, make, make install. So writing an ebuild really isn’t that hard. And portage can generate RPMs for packages it has already built. If someone were to add the functionality for deb tgz then you’d have your tool.
jhbuild, GARNOME or cvsGNOME
For gentoo users: breakmygentoo.net-s gnome-current from the cvs, or wait to release a .tar.bz2
Everything works fine for me except evo-1.5.4 that crash sometimes
Can someone post a screenshot of the new file selector? Thanks.
It anyone has good screenshots yet, please post them
http://sayamindu.t35.com/GNOME_2_6.html
http://www.terra.es/personal2/hey_neken/gnome/selektion1.png
http://www.terra.es/personal2/hey_neken/gnome/selektion1.png
http://www.terra.es/personal2/hey_neken/gnome/selektion1.png
Hi! I made them fast, but thats what are you asking for no?
Hey_neken
http://www.terra.es/personal2/hey_neken/gnome/selektion1.png
http://www.terra.es/personal2/hey_neken/gnome/selektion2.png
http://www.terra.es/personal2/hey_neken/gnome/selektion3.png
Hi! I made them fast, but thats what are you asking for no?
Hey_neken
Showing a screenshot once would have been enough, eh? 😉
http://www.terra.es/personal2/hey_neken/gnome/selektion2.png shows a funny usage of autoamtic layout management.
http://www.terra.es/personal2/hey_neken/gnome/selektion3.png shows what problems deep paths will cause.
Yes, that is what I was asking for. Thank you very much. Interesting changes to the file selector.
Yes, alot of features doesn’t mean a bloated piece of software, But optimizing for speed performance must be a goal in its own and must (in my opinion) be of higher priorty.If Gnome or let me say Gtk+ aren’t keeping in their mind increasing performance then we’re in big trouble.
Thanks for the screenies! Nothing too new visualy I guess, eh?
Up2date file-selector screenshots (hungarian-english):
http://web.axelero.hu/hrvatska/pics/file_roller.jpg
http://web.axelero.hu/hrvatska/pics/gedit_save_as.jpg
http://web.axelero.hu/hrvatska/pics/open_extended.jpg
The layout issue is fixed in latest CVS (perhaps in beta 1, but I only use CVS head nowadays). Also, the “Choose a folder” dropdown is fixed.
About the long path, in case it’s quite long, arrow heads appear on the sides of the path widget to scroll. And the “Create Folder” button isn’t in the standard GTK filechooser. Seems like something Gedit added.
What happens when trying to access deep paths? From the screenshots, anything more than four or five levels deep will be an issue for displaying buttons above the file names.
I see my question was answered as I was typing it in. Thanks, Rick.
I like it…but one thing bugs me. I think the buttons above the file names should be changed to tabs to keep the interface consistent. Other than that it looks great.
This is all well and good, but after taking a peek at the latest build of Longhorn, I’m a bit worried. I think that Linux has finaly cought up to Windows XP visualy and usiability wise, but how are we going to compete with Longhorn? Are there any plans for more Gnome eyecandy?
Is it just me or all the links to the screenshots are broken there?
Victor.
Longhorn is 3-4 years away. In the short term we need 3D Accelerated X-server and GUI. Then we can add any good features of Longhorn. We can already beat out most of it, but until X gets an overhaul for the 21st century, we are going to be behind. We need Quartz style 3D enhancement for our window managers, and X. Also not every Window manager needs 3D enhancment, just the ones designed for the general population, Window maker and other minimalists, wouldn’t need such power, but KDE, and Gnome would.
> This is all well and good, but after taking a peek at the latest build of Longhorn, I’m a bit worried. I think that Linux has finaly cought up to Windows XP visualy and usiability wise, but how are we going to compete with Longhorn? Are there any plans for more Gnome eyecandy?
Well, for one Longhorn is not out and won’t be out until 2006. Seeing how fast GNOME has evolved in 1/2 years, you can be sure that GNOME will be amazingly great in 2 years. And I have no doubt it will be better than Longhorn in a lot of aspects.
Now, when talking of eye candy, I really don’t see your point. MacOSX might be very nice-looking, but I fail to see how Longhorn could be considered “eye-candy”… For me, it’s just ugly, and I hope GNOME won’t try to imitate it.
I like it…but one thing bugs me. I think the buttons above the file names should be changed to tabs to keep the interface consistent. Other than that it looks great.
The gnome people hate tabs. Everybody says tabs have some really serious UI issues… (nobody says which issues are these, though).
Victor.
If you want to reach deep paths, you have 2 possibilities:
– you right click on the first folder and choose “browse”
or
– you use middle-double-click to automatically close parent folders after opening sub-folders
“The gnome people hate tabs.” …well that’s a shame. It’d look better with them. Different sized buttons make it look ‘bitty’ and less organised…maybe it’s just me.
…still like it though
> And the “Create Folder” button isn’t in the standard GTK filechooser. Seems like something Gedit added.
This is bad. No useable file selector and looking different in each application.
> Is it just me or all the links to the screenshots are broken there?
This mirror is better: http://www.clai.net/sayamindu/GNOME-2.6/GNOME_2_6.html
Is gnome-terminal still as slow as usual? I.e. can you still see it redrawing itself when scrolling pagewise up in less(1)?
The reason some apps will have a different file selector is because they need one. If you lookat some of the screenshots posted, you will see that fileroller, for example, has far ore widgets on its file selector than normal, because it needs them. It is bad usability to include things that won’t be used by the app.
What is that theme the reviewer is running? Anyone know where I can find it? looks real nice.
I have nothing against variable parts which extend the dialog at the bottom or the right but within the central widget and even reducing the width for this path widget?
When will they really fix the file selector? GTK 2.6 I’m guessing. The one in 2.4 is an improvement, but still doesn’t seem all that great.
I think it is thin. I think it comes with most distros.
In the short term we need 3D Accelerated X-server and GUI
Have you used freedesktop.org yet? Phenomenal eye candy! All it lacks are drivers, more KDE compatibility, and a little bit of stability. Even in vesa the windows (with shadows and transparency!) moved smoothly. Combine kde3.2, gnome 2.6 and fdo, and you have yourself a longhorn beater!
I think you judge it too early and too harshly. A file selector isn’t something whose usability you judge from a screenshot. You use it, and find out if it will do what you want it to do or not. In F1, they generally say a car is not beautiful if it doesn’t win a race, and you could say the same thing about this file selector. It is useless if it doesn’t do what it supposed to do.
Also, I too think that in the 2 or 3 years Longhorn will take to be released and another half year to become popular, KDE especially and GNOME and the new X server will be ready to take it on.
@gabrielebner
Is gnome-terminal still as slow as usual? I.e. can you still see it redrawing itself when scrolling pagewise up in less(1)?
That’s mainly dependent on your video card and drivers. Poor render extension support with most video card drivers is to blame for that. I don’t see it redrawing when scrolling at home because my card has good render extension support.
The window manager theme is called “Digital Cream”. You can get it at art.gnome.org
I argued for tabs when Seth and JRB were coming up with the new file selector, but the problem with tabs in this interface is that tabs are never supposed to be destroyed.
Think about it: when you click on one of the path buttons, all buttons to the right of the one you clicked on _dissappear_. When was the last time you were working with tabs and half of the them _dissappeared_? That’s the problem with tabs here, it breaks the tab metaphor. I didn’t think it was such a big deal, but others did and they are actually correct.
Dan W
I’ve seen the minimalistic view of the Save As dialog and I have one big reservation with it: no information is provided by default on the file’s location.
This would have been fine if a majority of users would never need to know the file’s location, but there are many tasks which require it. Transferring a file, mailing it, or copying it are just some of the few activities that would require knowing where a file is located.
Note: I’ve used the term “majority of users”. If the majority of users would have to click on the “More info” tab then that information should be displayed already.
No, it is quite ok really. You should get a drop down of your favourite locations, which is where many people save their docs anyway. It is too easy to get the full folder list.