GNOME 2.16 Released 473
Kethinov writes "The GNOME Project has just released version 2.16 of their popular *nix desktop environment. Among many snazzy new features, is lots of new eye candy, including an experimental compositer in Metacity, feature enhancements, usability improvements, and much, much more. Ars Technica has a review."
Awful default "X" icon (Score:1, Interesting)
Visual Improvements? (Score:1, Interesting)
Not bad, except (Score:3, Interesting)
I really wish they wouldn't use JPEGs for computer screenshots -- the lossy compression makes straight lines and text look terrible. PNG (or possibly GIF, depending on the number of colors used) is much more reasonable.
Other than that, I don't understand why the --enable-compositor compile-time option isn't included by default. Logically, if the support is there, but the hardware isn't up-to-par or the X composite extention is not loaded, then the compositor just won't do anything. If everything is A-OK, then the compositor works as expected. For example, I compile support for my sound card directly into my kernel. One day, if I suddenly remove the sound card, my kernel will still work. So why not just turn stuff on by default?
On the other hand, I can understand why some things aren't compiled in sometimes, due to size, but a compositor can't be more than, what, 100k of actual code? Anyway, I'm sure someone's gonna fire back at me.
Re:So? It still sucks. (Score:3, Interesting)
KDE has many things going well for it. This'll sound weird, I'm sure, but I like Gnome better because it feels better. KDE has a weird feel to it that I can't get over. It's the same feeling I get when I use Opera, I don't quite like it.
KDE also seems very thrown-together, and there are icons for almost every single menu item in almost every single menu -- it makes the entire desktop look extremely cluttered. Some lines and shapes (in some dialogs, some programs) are off by just a single pixel from where they should be, but because of that small error, it makes the desktop look slightly askew, and adds to the screen clutter appearance.
Other than appearance and "feel" I have no problem using KDE.
Re:The important part: Mono (Score:1, Interesting)
Technically great (Score:3, Interesting)
If you want to do flat shadows, cool, do them, they're easy and effective. If you want to do three-dimensional shadows, cool, they look even better but take a bit more work. But don't drop the same blurry ellipse at the bottom of every object and think that you're making a three-dimensional shadow, you just make everything look like it's standing on a blurry gray oval, and users really do recognize the less professional look, consciously or not.
Re:candy (Score:5, Interesting)
Don't fade borders if you're compositing a complete window. Faded borders are the graphical equivalent of an ellipsis.
And definitely don't add a drop shadow to something you've already faded to white. It looks ridiculous.
Re:The important part: Mono (Score:3, Interesting)
The GTK+ theme engine is lacking. (Score:1, Interesting)
One of the main causes is their use of C. It doesn't promote a solid rendering class hierary, as is offered by GUI toolkits that are written a language like C++ (eg. Qt, wxWidgets), Objective-C (eg. Cocoa), Java (eg. Swing, SWT), or Smalltalk (eg. Squeak). This in turn makes it quite difficult for anyone who wants to develop a theme of any complexity.
Like you mention, just changing the colors (which is easy enough) is not enough. You need to be able to render button and text fields with shadows. You need to have certain corners be sharp, while others rounded. The toolkit engine of GTK+ allows for both, but doens't easily allow for both to be used concurrently.
That's just a small example of the problems that exist when writing a GTK+ theme engine. What needs to be done is an analysis of what successful GUI toolkits, like Qt, have done. Adopting the techniques of their engine is perhaps the best thing that the GTK+ developers can do at this point.
Re:The important part: Mono (Score:1, Interesting)
I use Linux 100% of the time at home AND at work. I only develop on linux for linux.
I could really give a shit less about Microsoft and what they do.
I do enjoy Mono though.
Re:But does it have a useable file-save dialogue? (Score:5, Interesting)
Re:Almost sounds like KDE 3... MOD INSIGHTFUL (Score:3, Interesting)
Why has it taken this long to be able to set recursieve file permissions ?
Why has it taken until now to be able to edit the menu (smeg notwithstanding) ?
These features should have been in from release 1.0
Sorry but GNOME really does suffer from some pretty basic usability problem which, as the parent posints out, could mostly be fixed by taking note of some of the good aspects of GUI design that have been put into place over the last 20 years, and especially by allowing users to set options as they want - not what the designers think is "best for them".
The "we know best" attitude is condescending and hinders usability. The "proper" way to do it is to have everytthing come "out of the box" with basic defaults but let the user "open up" the interface as they learn it. If you're really worried about your poor users provide a "reset to defaults" option.
The parent post simply points out some obvious problems with GNOME, the fact it got modded Troll points out some problems with blinkered moderation.
And yes I am a GNOME user - I have an Ubuntu desktop at home. I mostly like GNOME but it always, always sends me into a swearing frenzy due to basic usability problems.
Re:Almost sounds like KDE 3... MOD INSIGHTFUL (Score:2, Interesting)
Re:The important part: Mono (Score:1, Interesting)
Just like Java is a standard.
Java isn't standardized [wikipedia.org] by anyone other than Sun. C#, on the other hand, is standardized by ECMA and ISO [wikipedia.org], not Microsoft.
Could you explain why grammar parsing is not possible in C#? There isn't any kind of magic that C++ can do with strings that other languages can't. Sure, there might be libraries to do grammar parsing for you that are written in C++, but there isn't any reason these libraries couldn't be written in another language or that bindings for other languages couldn't be written.
I love and use C++; I just don't like this "anything but Microsoft" criticism of C# just because a Microsoft employee created it. If you're going to discuss a language, let's talk about its technical merits, not the employer of its creator. The advantages that C++ has over higher-level languages are primarily (A) it's C compatible, and (B) it allows really low-level control (like C does). (A) is a non-issue once bindings have been written for a C library. (B) is a valid advantage, but it's really only important in things like operating systems or applications where performance is really critical. This applies to only a small minority of software nowadays.
It is true that C++ has gained a lot of the features that other languages have with the Boost libraries. However, the nature of C++ makes it so that, even with Boost, code is more cumbersome than in high-level languages. Take, for example, passing a function as an argument to another function. Let's say I need to pass a function called "clickHandler", which is a member of the class window, whose prototype looks like: void clickHandler(Event ev); I want to pass this function to another function called registerHandler (which makes it so when the user clicks on the window, clickHandler gets called). Using boost, my function call looks like:, this, _1));
registerHandler(boost::bind(&window::clickHandler
and registerHandler's prototype has to look like:
void registerHandler(boost::function<void (Event)> func);
Now, let's say you try to do the same thing in Python. Your function call will look like:
registerHandler(self.clickHandler)
and registerHandler's definition will look like:
def registerHandler(handler):
I don't know the language well enough to know what this looks like in C#, but my point here is that yes, you can do things in C++ that you can do in higher level languages, but it's often much more unwieldly and difficult. It took me a really long time to figure out how all that syntax for Boost and C++ works the first time I learned it; if you look at the C++ code above, you certainly can't say it's blindingly obvious that that's how it should work. When I learned how to do this in Python, all I had to learn was "Functions in Python are objects." and that's enough information to write the code. Not only that, the Python code is much more flexible; if I change clickHandler's interface, I also have to change registerHandler's interface and the (potentially) function call, whereas I don't have to do anything if I change registerHandler's interface in Python (beyond any necessary changes to the logic (not syntax) of the code). The idea of higher-level languages is that you don't have to micromanage tasks like how a function is passed as an object; you can focus on the bigger picture, which is that you simply want to pass the function.
Sure, C++ is more powerful in that you can micromanage things like this if you want to, but usually you won't want to, and with languages like C#, Java, Python and others, you don't. Processors have gotten a lot faster and memory has become much more abundant since C++ was created in the 1980s, and the tradeoff between the computer clock cycles and programmer "cycles" has shifted. This is why GNOME and other software projects are making increased use of higher level languages.
Re:candy (Score:1, Interesting)
When I see a system that configures itself so flawlessly as for example win XP or os X, and is so stable, dynamic and fast as linux, im happy. Right now, im sorry, im NOT.
Windows XP is very underestimated by many Linux powerusers, in the sence of easy-too-use and compability.
Yet STILL... (Score:5, Interesting)
(I still use gnome every day.)
Re:candy (Score:2, Interesting)
I'm with you. Sure, there might have been issues with maintenance of the Sawfish code, amongst other things, but metacity still has a couple of glaring holes they refuse to fill in.
My own pet peeve is Metacity's refusal to remember the size or positioning of windows. I know the developers claim it's the application's job to do this, but I don't agree. Seems obvious to me, but who am I to insist that a window manager's job is to manage windows?
Re:candy (Score:4, Interesting)
I think one visual design principle is this: if visual differences carry information, then pointless visual differences convey spurious information.
The screenshots in question also seem to me to be a bit of a mixed metaphor. The drop shadow makes the things stand out from the page. This, I think, is an OK idea; it's not so much that the drop shadows tend to draw the eye to the screenshots (which they do), but it also conveys the messaage that these are concrete examples we are discussing; that is to say if we're looking at a screenshot of a graph, it's the window we are paying attention to, not the graph inside. By contrast, if there a graph that showed something like the lines of code in Gnome vs. time, you wouldn't expect it to get the drop shadow treatment.
The mixed metaphor comes in this way: by fading the borders, the windows become less solid, yet they are still casting a shadow. The shadow appears to be cast by a sharp edge from a diffuse light source, but there is no sharp edge.
What does it mean? It means nothing. Therefore it's poor communication because, unlike the drop shadows, it detracts from what is being said.
Re:But does it have a useable file-save dialogue? (Score:4, Interesting)
Documentation is what always sucks in Linux desktop. Check out for once M$Windows one.
I loved GNOME 1.x for it was lean and clean - with most of the little bits been documented. I hated KDE1 precisely because it had only dummy automatically generated documentations. Many years have passed and situation reversed 180 degrees: KDE is documented and GNOME documentation is dumb-down to complete unusability level.
I'm given myself a word to not use GNOME until its developers would not document all the magic behind .gtkrc and .gnomerc files - and how the two are interconnected. It was safe bet - no documentation in last 3-4 years emerged and I do not use GNOME anymore ;)
Are the dependencies still growing like topsy? (Score:3, Interesting)
When the number of dependencies required to run Gnome on mainstream distributions DECREASES, that'll impress me. Until then I am unlikely to care what new eye-candy it's sporting.
Re:Technically great (Score:3, Interesting)
Pretty easy, actually. Using Inkscape, for example, if you already have the main icon drawn:
Takes less than a minute. Sure it would take a bit more work than just copying and pasting the same grey oval, but not much, and it's literally the same process for every icon, once the main part is drawn.