GNOME 2.20 Released 443
Gimli writes "GNOME 2.20 has been officially released. There are a number of enhancements and improvements to things such as power management, Evince (the GNOME document view), Totem (the video player), and note-taking application Tomboy. There are also some changes to GNOME's configuration utilities with an eye towards streamlining them. The timing is impeccable, too: 'This release coincides with the tenth anniversary of GNOME's existence. The project has evolved considerably since its earliest incarnation and has become a global phenomenon. Used as the default environment in popular Linux distributions like Ubuntu and Fedora, GNOME is widely used by Linux desktop users and is supported by a growing community of companies and independent developers. GNOME 2.20 will be included in the next major releases of many mainstream Linux distributions, including Ubuntu 7.10, which is scheduled for release next month. Users who wish to try it now can use the latest Ubuntu 7.10 live CD images, or the latest build of Foresight Linux. You can also check out the release notes."
Power Management? (Score:4, Interesting)
power management? (Score:2, Interesting)
tomboy (Score:4, Interesting)
Including a minor tool for a trivial task which takes as much memory as the rest of core Gnome together is something I can't really understand. It's the only part of Gnome proper which uses mono -- so why do they bother shipping it?
Of course, asking whether major annoyances like new windows opening on whatever workspace you're currently on instead of the one they were started have been fixed is kind of pointless...
Unix Gnome (Score:4, Interesting)
GNOME has many flaws, but it's far superior to CDE. IMHO, that's because CDE is a child of politics and bureaucracy, while GNOME grew up organically, with various developers exercising their intelligence, insight, and creativity in order to make it a better product.
Re:Unix Gnome (Score:2, Interesting)
Sun. That's one. I'm unable to think of others to fill out the "many Unix vendors" you are referring to. Apple doesn't. The BSDs don't. SGI doesn't (didn't). I don't recall that HP does. Who am I missing?
Congrats! (Score:4, Interesting)
Re:Lameness (Score:5, Interesting)
See, that's why I put the parenthetical in there, I am a programmer, but I'd prefer 2 features that both work right to 1,000 that half work. To me, the latter is morally equivalent to lying. Although Gnome absolutely has its share of problems, it's well ahead of KDE as far as actually working. I keep an updated KDE installed on my desktop and check it out at least every 6 months--mostly because Gnome isn't good enough either, but it's the best I can find. The thing is, I jump into KDE, and within a half hour I've found four things that don't work, cause crashes, silently fail, or just suck (by just suck I mean unresponsiveness, the crappy menu transparency and shadows that are off by a couple pixels that's completely different from the crappy window transparency, which isn't even consistent in itself!).
As for the list of junk I rattled off for Gnome, yeah, you got me, that's just what I remember from when I was going to help out with the project a few years ago. After realizing that I'd have to learn 40 different, sometimes incompatible, often redundant frameworks, I decided my time would be better spent elsewhere. And yeah, I do have something that will be coming out Real Soon Now (had to take a break from programming due to tendinitis in the wrist that's still bothering me to this day) but the point is, Gnome looks like it does not because all that crap actually helps out, but because 50 different people had a Great Idea.
No, wait, there is no point. Oh! Here's one: A project as big as a desktop environment that needs to be extremely consistent throughout, needs a Linus. It needs one guy to be the benevolent dictator, because right now it looks like anyone can get any old thing in there. Tomboy a C# app? wtf? It's not complicated, it's an applet, a couple borderless windows, and a simple WebDAV client, all of which I'd bet lots of money Gnome already has libraries for. It could be just as easily implemented in C, and a halfway experienced Gnome developer could implement it, with all of its current features, in probably a week or less. I'm halfway tempted to take a week of vacation and do it myself just to prove a point.
Re:Unix Gnome (Score:3, Interesting)
Re:Dons the asbestos suit.... (Score:3, Interesting)
I may be biased since I've been using KDE for years and have never known it to crash, but I have to ask - what proportion of Ubuntu users would you trust to correctly differentiate between a KDE crash, an X Server crash or a kernel panic/Oops? Also, if you're putting forward Ubuntu as the gold standard of stable packaging and quality control then your opinions may not be treated with the respect you may think they deserve.
If you can find similar opinions amongst users of Debian, Red Hat, Slackware, Suse or any of the BSDs, do come back and let us know.
Re:Mono isn't part of GNOME (Score:3, Interesting)
You can even run a completely mixed environment. For example you could theoretically run GDM (the Gnome session/logon manager) with Nautilus (Gnome) to handle the Desktop, use the Fluxbox window manager (not Gnome or KDE), have Kicker running (KDE Panel/Menu bar) and use Konqueror (KDE) for the file manager. Or just about any other weird combo you could think of.
Gnome may have more users than KDE (or maybe not), but in any case KDE has millions of users and a very large and active Dev community.
Mono has official bindings for Gnome, and is fully supported for writing Gnome apps. Aside from Tomboy; Beagle (search), F-Spot (photo management) and Banshee (Music player) are all Mono. However it is extremely unlikely that anyone will rewrite Nautilus, G-conf, Gnome Panel or any other core part of Gnome in Mono.
Re:Totem (Score:2, Interesting)
Find out more at http://dekorte.homeip.net/download [homeip.net]
Yeah these are my apps...
IMHO Gnome 1.4 was the best (Score:4, Interesting)
There are a number of enhancements and improvements to things such as power management, Evince (the GNOME document view), Totem (the video player), and note-taking application Tomboy. There are also some changes to GNOME's configuration utilities with an eye towards streamlining them.
Sure, and meanwhile, Program Manager (Windows 9x) and Presentation Manager (OS/2) did more with less memory (Two Meg), back in 1995.
Whats really sad is that Presentation Manager was OOP/Class aware which is what both KDE and Gnome are still striving for.
Congrats to the Gnome team. Hardware companies everywhere salute you.
If I bitch about system requirements for Windows, then I can bitch about system requirements for Gnome/KDE.
I won't be downloading Gnome. XFce4 is everything Gnome was suppose to be. How many Gnome programmers use XUbuntu for development?
And where in the hell is the new Enlightenment Ebuntu distribution?
Enjoy,
Re:tomboy (Score:3, Interesting)
That's bullshit. Every gnome applet or application on my machine has an RSS between 5 Mbytes and 15 Mbytes, and there are dozens of them. Tomboy has an RSS size of 26 Mbytes, which is more, but not a lot more.
But unlike all those other applets and tools, you would only need a single Mono VM to run all applets and most applications safely together. If it were fully based on Mono, you could probably run the entire gnome desktop in a small fraction of the memory it's using now, and you'd laugh at the silly suggestion of writing anything in C because it's just too inefficient.
It's the only part of Gnome proper which uses mono -- so why do they bother shipping it?
Because they realize that Gnome can't survive as a desktop that's being hacked in C/C++.
I really don't know whether the Mono VM is the future for the Gnome desktop. But I do know this much: C, C++, and Python are not the future of desktops.
Re:I have to ask... (Score:5, Interesting)
The problem with xfce or gnome is not the choice they made per se, but the fact that you can't actually get out of them. If you happen to be a person that don't fit what they see as a regular user and what is good for you, you just can't have a good experience with their desktop.
So yes, the KDE control center is crammed with features, but I only know and use those that I need and I have turned the desktop into a wonderfull, simple and sane experience for me. A thing that I can't do with GNOME, XFCE or any Windows.
And before you actually dismisses me as a KDE fanboy: I was a GNOME user prior to their stance on "forced down your throat" usability. I had also all "regular users" I knows of try the GNOME desktop so that I don't force my choice on them and they all prefer KDE. So this is not a representative panel, it's just a familym but they are supposedly the target of this usability choice, but either because its defaults are windows like (wife used windows at work before they switched to Linux), either because they can turn it into a strange unbearable carnival of colors (youngsters), either because they can drag and drop all their heart between applications (grand parents) or because I can heavily customise it to suit my day to day work, everybody chose to use KDE.
I'm sorry, but when I use the console it doesnt force me to use that command to another because it's "THE right way to do it", I can choose whichever I see fit for the job and pipe them into an unthought of combination.
That's the part I like about the unix philosophy.
To me the GNOME usability choice were not made to suit the users, but to suit the helpdesks. Users are versatile, I dislike and I'm even worried by this computer behavior which asks the user to fits the system and not the other way around.
Re:Lameness (Score:1, Interesting)
Besides the fact that C++ is "the PDP-11 assembler that thinks it's an object system"?
Gnome has always encouraged high-level bindings for just about everything they do. C, and in particular GObject, is really easy to make great bindings for. Gtk+ may be a bit verbose from C, but PyGTK is a dream for Python programmers.
To put this in Ballmer terms, Gnome is pretty darn good about "developers, developers, developers". They have orthogonal libraries (cairo, pango, gtk, gconf, etc.) that you can take or leave as you like. They're good for using from whatever language you like. They're LGPL, so companies writing proprietary apps (like Real) are willing to use them. The documentation isn't great, but it's pretty good. "Pretty good" on every axis, in my book, is quite rare.
In contrast, once you're in C++, you're kind of stuck in C++. I've had to develop large apps in PyGTK, and large apps in PyQt, and PyQt can be quite painful. Unlike PyGTK, I never felt like I was developing a Python application. It never lets you forget you're using a C++ library underneath. I really don't want to have to think about C++ memory management when I'm writing a Python app, and abstracting it away is apparently non-trivial.
I don't know what you mean by "500 different code generators" or "hardly recognizable as C". Looks like plain ol' C to me. [gnome.org] If you want to see scary code, look at OOo sometime (which is in C++, coincidentally). Gnome is among the cleanest code I've seen, for a project of its size.
Always been buggy (Score:3, Interesting)
Users don't want buggy software even if it appears that new features have been added.
There are some real show stoppers in gnome. Interesting that for release after release they haven't fixed them. One of them clearly can be demonstrated by copying large numbers of files on a network. You'll be regularly prompted for generic errors about the copy process. You can retry and the file MAY be copied. Moving files over a network is not a safe endeavor. Yeah yeah, small groups of files are ok, but large groups can result in you thinking the process has completed when it really didn't complete the process.
So, some serious show stoppers yet we get a
FIX THE BUGS!!
Sorry, just couldn't resist.
Re:I have to ask... (Score:1, Interesting)
Re:I have to ask... (Score:5, Interesting)
However, I also have the flexibility to customise it to be productive for me.
KDE is also more functional than Gnome. Genuinely useful panel applets, preview, tabbing and split window functionality in Konqueror, etc. are actually very useful.
I like the elegance of Gnome, so I have tried it several times. I find it less functional, and a lot of functionality works less well (compare opening a directory over sftp in Konqueror and Nautilus, for example).
C, C++, ABI compatibility, Vala (Score:2, Interesting)
You may not like GObject, but it is a very powerfull library. It may not look very nice, but it does its job and it does it rather good.
You see; I'm a programmer. And I really don't know what to do with C++. It looks ugly and brings some OO concepts to c, at a terrible price. No standard ABI, problems with the linker all the time, difficult to bind to other languages. I
C on the other hand? Well, it is not very beautifull. And if you add the curde syntax of GObject, it's plain ugly. But at least you have a stable ABI and don't have to recompile everything and its mother if you change the compiler. And GObject makes it very easy to create bindings to scripting languages. Python, jay! Ruby, jay! And now with Vala, creating GObject based libraries gets even easier.
C++ is not a language for the future. Something like D is; nice syntax, memory management, compatible to c libraries.. Heck; with GObject, I'm sure its quite easy to create D bindings.
C just stays the common denominator of most programming languages today. And because of that C is the perfect choice to build libraries upon. And with GObject, though it may be pig-ugly and crude, even OO is not excluded.
Re:Not for free (Score:3, Interesting)
Well sure, you have to use some libraries either way, but in kde, when you open the standard "Open file" dialog, you get kioslave (network transparent file access) "for free". The file dialog supports it, and there is no extra work involved on the part of the application developer. Same with the toolbar, no KDE application developer would ever have to conciously think about whether they want to add support for editable toolbars, because the toolbar classes support it.
But that's not a problem of KDE vs. Gnome, that's a problem stemming from the fact that a lot of programmers only use a part of Gnome (GTK+) instead of using the whole environment.
Exactly. So the question is, why not? My theory is that the libraries are too fractured. GTK provides too little, so for basic features you need to pull in a bunch of external libraries. I can understand why some app developers just don't bother, because it's extra work, and they want to minimize the external dependencies. With KDE apps, you just need to link to kdelibs and you get pretty much everything. Of course that means that one standalone app will be heavier than it could be, but once you run the whole desktop, you end up using the same amount of resources, and each app gets all the features, so from a user experience point of view, it's more consistent.
Hopefully this will be addressed in GTK 3. I heard they are planning on merging a bunch of previously external libraries.