The Gnome Project released version 2.12 yesterday. We had a quick look at it by using the latest Gnome Live CD (1.12-pre) and Foresight 0.9.0 (2.12 final) and here are our thoughts over 2.12 and Gnome’s status in general.The new features
The first visual change a user will see after loading Gnome 2.12 for the first time is a brand new default theme: Clearlooks. The theme is very clean, concise and most distributions and power users have already adopted it months ago.
Nautilus now features a “path navigation” scheme too, similar to the GTK+ file selector’s. The old text navigation input box is still available, but unfortunately not through a preference option, but only via a shortcut. There is also an updated sidepane on Nautilus now, with more views: bookmarks, places while Nautilus now also sports a spatial tree file view. The “Open Terminal” Nautilus menu option is now removed, and users will have to manually install a third party plugin to get it back or by using the right script.
On the core side, GTK+ 2.8.x now depends on Cairo which offers vector support among other things. Drag’n’drop was also improved, while Gnome now features clipboard management, meaning that you don’t lose your clipboard’s contents if you close the application that generated them (this is the default X behavior). HAL also works better with GnomeVFS now; I was able to mount my iPod Mini easily.
There are a few new applications integrated to Gnome Desktop now. The “About me” application which allows you to insert your personal information once and then have application reuse that information automatically, much as how it happens on PDAs. The mouse preference panel now allows you to select cursor themes, but unfortunately it doesn’t let you install new ones. Totem is now part of Gnome and hopefully Rhythmbox will follow on Gnome 2.14, while Sound Juicer has major new features, such as song preview before importing. The Keyring application is also now included, but I must say that I don’t personally have a great need for it. Evince is also now part of Gnome. I like Evince very much, however poppler (its underlying library) is pretty buggy. See the last screenshot for more.
Small changes and feature additions were also made to the Dictionary app, Epiphany (handles RSS), EOG, Gnome panel, Help Viewer, Search, Battery applet, “Add to Panel” applet, Evolution, Weather applet, CD playback applet and more.
On the administration side, you will find the Gnome-system-tools package which supports networking, user & groups, Services and Time & Date. Please note that only a few distributions are supported by these panels (Debian, Ubuntu and Fedora seem to be the best supported of the bunch). Sabayon is also there for those who want to play with user profiles, even if not officially part of Gnome yet. I must say that I don’t fully ‘get’ Sabayon: its Help files are less than helpful. Two more new administration applications are the Log Viewer and the Menu Editor. I don’t like the current menu editor as it is very under-featured. You can’t create new shortcut items, only make the existing ones visible or hidden. Smeg will still be my number one choice regarding menu editing.
General thoughts on Gnome
It’s been a few years since I reviewed Gnome for the last time. Since then, Gnome has matured and made most things right — except the spatial Nautilus that I personally don’t like and the downplay of the Nautilus scripting/plugin engine. But all in all, Gnome is today more powerful, better integrated to the underlying system with DBUS and HAL, looks good, behaves as expected and, most of all, it’s simple and clean. In my opinion, the Gnome Desktop is the best X11 desktop system today from the user’s point of view when compared to the rest of the DE solutions.
However, the biggest two problems I see on Gnome today are:
1. Incomplete/confusing API documentation. New developers have to read source code and beg on mailing lists to get their code up and running instead of having a complete and sane documentation at their disposal like Qt developers do. If KDE has the upper hand in one thing over Gnome, it is their great RAD tools and API documentation, both provided by Trolltech, a commercial company that have perfected these tools and their docs for their own business. Without developers that have good tools on their hands, no platform can go anywhere. It’s all starting from the developers and the Gnome Project must pledge extra care for their new or potential developers.
2. The pace of development seems to be slower than in the past, it seems that not many major features are implemented anymore, at least not enough compared to KDE. Gnome 3.0 is still a long way off and as an (occasional) Gnome user I want to see more action. KDE has a full front-end to the Bluetooth stack, for example, Gnome has none (except Edd Dumbill’s third party ‘Gnome Bluetooth’ which only supports one (Obex) of the 7-8 common Bluetooth functionalities). Phone and PDA syncing that actually works is a must too (no, Gnome Pilot doesn’t count anymore). Memory and speed optimizations would be most welcome too.
Conclusion
Gnome 2.12 is an evolutionary step in the 2.x release. Gnome could still add more features or applications, pay more attention to the detail and further improve usability. However, even as it is today, Gnome 2.12 is the best X11 DE there is. Given some more enthusiasm and features & better dev tools and docs, Gnome will have nothing to fear not only from underdog & lean XFce, but not even from its closest rival, the feature-rich KDE. Gnome is the king of X11’s user experience.
Note: the hardware used was a 2.8 GHz P4 LinuxCertified laptop.
Overall: 8/10
All in all I agree with this review, however, why the author thought it was a good idea to flame KDE in a Gnome review is simply beyond me.
Flame KDE? I simply mentioned it and compared it. I don’t see where the “flaming” is, in fact the first two times I mentioned its name on the article I gave it the upper hand on the specific issue discussed in the paragraph!
I think you are too touchy and you can’t see the words “gnome” and “kde” on the same article.
“Flame KDE? I simply mentioned it and compared it.”
That’s exactly my point, you didn’t compre it at all, you simply declared Gnome to be king.
“I think you are too touchy and you can’t see the words “gnome” and “kde” on the same article.”
Maybe I am, but I’m just so sick of all these stupid Gnome vs. KDE flamewars and I think the way you mentioned KDE in your review will inevitably lead to one, even though I’m sure that wasn’t your intention.
I 100% with the person who made the initial comment. Within the article body the only thing stated was KDE’s advancements and benefits above and beyond gnome. Then, within the summary, the reviewer says gnome is the best (ie better than kde) but makes no points to support such claims. This makes it obvious that the reviewer doesn’t care to stick to facts which results in a poor review.
I can form my own opinion. I am interested in legitimate claims (ie not baseless/unsupported).
I thank the original commenter for pointing out this. I was going to point this out myself if he/she had not done so.
If you were taken the time to understand the structure of the article you would see that the two times KDE was praised were on the two paragraphs that detailed the DEFICIENCIES of Gnome. Praising KDE at these two times DOES NOT MEAN that on all the rest of points KDE prevails or not. KDE is mentioned there to simply help make the case for these two gnome problems. This article is not a full comparison of the two DEs. But having used both, as a normal user, I still prefer Gnome over any other X11 DE. You are free to disagree and submit a comparison review.
Hey,
Don’t get me wrong. I was simply agreeing with ralph. And you are welcome to disagree with both of us. We’re simply the readers. What do we know?
“If you were taken the time to understand the structure of the article”
I read it over a few times to try to understand your summary paragraph. I couldn’t. Maybe I am dumb.
People are too touchy and sensitive over words. LOL
‘Gnome is better than KDE’ — Wahhh!!
‘No facts to support your statement’ — Wahhh!!
Ya big babbies. Go run home to mommie or something.
Although I have no comments on the item of flaming, I would like to say your comment back seems a bit out of place. I do believe you should defend your article but the last sentence was a bit of place.
But who am I to be telling an OSN Staff member what to do.
I do not understand why he claims Gnome is the best X11 desktop when wherever compared to KDE he gave it the upper hand.
He is a she.
All in all I agree with this review, however, why the author thought it was a good idea to flame KDE in a Gnome review is simply beyond me.
Pardon? I thought the review was quite fair, and was pretty favourable to KDE about the way it treats its developers and gives them the tools they need. In short, both desktops have different things to work on in different areas.
No flame here…move along.
So the big question on everyones mind is, how long until Debian Unstable has packages? Should we start making bets?
It appears that the Debian developers want GNOME 2.10 to enter testing in an orderly manner before introducing 2.12 to unstable. Remember that testing will become the next stable release and keeping this release procedure as smooth and organized as possible is much more important for Debian than pushing the latest packages to unstable as fast as possible. Here’s a recent post suggesting that 2.10 may be in testing soon:
http://lists.debian.org/debian-gtk-gnome/2005/09/msg00021.html
Who wants something designed for fools and morons ?
Developers don’t want code in linux until survive that stupid desktop
yeahh
I’m shocked that the new included menu editor does not allow the creation of new items. We waited 6 months for only a partial implimentation of a menu editor? This to me show one of the serious flaws in Open Source development. Developers typically only work on what they think is fun and intresting rather than boring little things such as the menu editor. Why is it so difficult anyway? SMEG works, why couldn’t they just use that if no one wanted to take the time to do it themselves?
Simon
Yea i agree this is another reason to shutdown gnome development on time for ever
SMEG works, why couldn’t they just use that if no one wanted to take the time to do it themselves?
As a GNOME user, I agree with you for the full 100%. Why they simply didn’t implement SMEG, a menu editor that works fine, is extremely easy to use, is completely *beyond me*. I’ve been thinking about reasons *not* to integrate SMEG– and I can’t think of anything else but…
…an ego problem. Seriously.
SMEG can be the default editor. My Ubuntu Breezy installation uses it, so when you right click and do ‘edit menus’ it uses SMEG instead of whatever that other one is. But I’m not sure if it’s because it’s Ubuntu or because I already had SMEG before I upgraded.
…an ego problem. Seriously.
Nonsense. It has been the plan from the beginning to only offer the required amount of functionality. Adding items is not required, because you should never need it if applications are not broken. Even then you can easily add launchers to your panel, put them in a drawer if you are short on space. The fact that they don’t appear in the menu is mostly a cosmetic issue.
If you need to fix broken applications and if you really want to make them appear in your menu, then it’s not difficult at all to install a different menu editor.
You may very well disagree with this thinking and you may be right as much as you may be wrong, but talking about “ego problems” is really cheap and inappropriate. Seriously.
>Adding items is not required
And WHO made the STUDY to really tell if it’s required or not??? Can you please direct me to the outcome of the user study made by the Gnome Project? Obviously me, Thom and others need the feature. I agree that for Gnome and KDE applications it should be considered “a bug” if an app comes without a working menu item, but there are other GTK, plain Qt, older X11 apps that don’t care about the freedesktop.org standard, and as a user, I MIGHT NEED this application to my everyday work. Therefore, I would want to add it to my gnome menu. Therefore, the current gnome menu editor is too little, and if I may say so, too late.
Exactly, Eugenia, I was about to post pretty much the same comment.
I’ve just been browsing through mailing-list archives and gnome-bugzilla, and I can tell from all the posts that the amount of people wanting *normal* menu-editing, like any other DE or OS has, outnumber the people against it. Actually, I couldn’t find *anyone* completely against users adding new menu items; most were indifferent to it (probably because only people like us join in ml/bugzila discussions, people that can do stuff like this manually).
Now, you are right that applications should conform to Freedesktop standards, and properly install a decent menu entry; however, not all apps will do that. Compare it to Windows; in essence, every app there should confirm to the admin/user divide in Windows; yet barely any app does that. So, there must be solution to this problem *inside* the DE that people use.
Other than that; how do you know ‘normal’ users do not need menu editing in GNOME, when it wasn’t available for quite some time now? If I got a eurocent for everytime I heard someone complain about the lack of menu-editing in GNOME…
I called this an ego problem because as far as I can tell, the descision to make menu-editing *not* a priority is a developer-inspired descision; not a descision based on user feedback.
Whether or not people *want* this feature is a different topic. It’s still mostly a cosmetical issue, because adding launchers does exactly the same thing, only visually different. This doesn’t mean that adding menu items is useless (although for me it is), but you should at least understand this point of view.
I called this an ego problem because as far as I can tell, the descision to make menu-editing *not* a priority is a developer-inspired descision; not a descision based on user feedback.
But that’s exactly wrong. There was never a decision to make menu-editing “not a priority”. It didn’t make it for GNOME 2.10, shit happens. Even before 2.10, the design for the current menu editor existed[1], so the reason the menu editor is in its current state is that it was planned like this all the way, not because developers didn’t bother to work on it. For power users plenty of alternatives exist already, so I fail to see the big problem. Whether or not a more advanced tool would be useful for everyone is obviously something people disagree about. It’s not an ego problem but simply a matter of different opinion[2].
[1] http://www.gnome.org/~calum/usability/specs/menu-edit/
[2] http://mail.gnome.org/archives/desktop-devel-list/2005-April/msg000…
I think you are underestemating the importance of this.
You are of course right that it isn’t the end of the world, but not having a well functioning menu editor is one of these little things that will annoy people to no end.
Just take a look at about every Linux related support forum and the amount of questions that were asked after Gnome 2.10 dropped menu editing altogether. I’m sure you’ll find thousands of questions about this, as you are going to find thousands again about not being able to add something to the menu.
And who cares about tools for power users? Power users can edit the .desktop file themselves if they have to, someone who is not a power user, but who simply wants to add a menu entry can’t.
To sum it up, this is one of those little braindead decision gnome devs seem to like to make from time to time, probably to keep us from getting to enthusiastic about Gnome.
And I think you are overrestimating the importance of this. Deal?
Why shall we keep running in circles, this is hardly different than the choice between Epiphany and Firefox. I like that GNOME caters to us lovers of simplicity by default. Distributions like Ubuntu can easily cater to a different user group. It is certainly possible for all of us to get along without calling each other braindead.
I like that GNOME caters to us lovers of simplicity by default. Distributions like Ubuntu can easily cater to a different user group.
The galling thing about this ‘adding apps to menu vs no adding’ argument is that it doesn’t hurt you lovers of simplicity to have the functionality. So why argue against it? For those who do want to add menu entries it is an inconvience to not be able to do so no matter how much you say we don’t need it.
And there may have never been a decision to make menu-editing “not a priority”, but there was a decision made to not use SMEG which brings up the question that started this thread: why did they not just use SMEG which is already a simple, functional menu editor that also has the ability to add apps to the menu?
I just don’t get people who will argue against having certain features when having them doesn’t make anything worse. Just don’t use the feature, but don’t tell us that we don’t need it.
“It is certainly possible for all of us to get along without calling each other braindead.”
First off, it wasn’t my intention to call you or others I disagree with braindead. So if I came off as doing this, I apologize.
“Why shall we keep running in circles, this is hardly different than the choice between Epiphany and Firefox.
I like that GNOME caters to us lovers of simplicity by default. Distributions like Ubuntu can easily cater to a different user group.”
I have to disagree here. I really can’t see how this is in anyway similar to the choice between epiphany and firefox and above all I don’t think this is really a matter of complexity vs simplicity.
While having the ability to add menu items might add to the complexity of the menu editor, not being able to do so is certainly makes adding a menu item far more complex now than it should be.
Finally, my point is that I don’t see any benefit from only giving the users a menu editor that lacks key functionality and again, if you don’t belief me, just take a look at the thousands of questions you will find about this very issue. People want this, people need this and nothing is gained by not giving it to them.
Eugenia… calm down
lol
Love & Peace…
>>Adding items is not required
>And WHO made the STUDY to really tell if it’s required or not???
Is a study really necessary? You seem to ignore certain points when you feel your position is being countered.
One point you completely blew by was, as stated in the post to which you wrote this reply, if the app isn’t broken, the user wouldn’t need to add menu items. In other words, if the app being installed includes a properly formated “app.desktop” file, as per FreeDesktop standards, the app would appear in the correct place in the menu. The user could then use GNOME’s included menu editor to remove it if he/she so desired.
If, on the other hand, the app is broken(read:no “app.desktop” file), there are other ways to handle it aside from menu editing at the user level. Such as adding a launcher on the panel or desktop or actually writing the app.desktop file and dropping it in to the correct directory(generally /usr/share/applications).
IMO, handling menu editing at the user level is wrong. It should be handled at the system level with an option for the user remove items from their menus if they see fit. As it stands now, that’s what we have. Provided, of course, that the app developers follow the standards laid out by FreeDesktop.
IMO, handling menu editing at the user level is wrong. It should be handled at the system level with an option for the user remove items from their menus if they see fit.
Why in the world do you care if I can or can not add items to the menu? How does it hurt you for me to have that ability? It doesn’t. So why are you arguing against it? If you don’t think you should be allowed to easily (without editing text files) add apps to the menu, fine, don’t do it. But why would you argue against others being able to?
Why in the world do you care if I can or can not add items to the menu? How does it hurt you for me to have that ability? It doesn’t. So why are you arguing against it?
Because it adds a button. Gnome is about removing preferences and ui elements. Simplify, simplify, simplify. Computers are complicated enough.
Applications should create .desktop-files. If it doesn’t upstream, the distro developers should do it. Many distros are always happy if someone files a bug about missing desktop files.
And if you install something from source, you’re knowledgeable enough to get smeg. Or, again, the distro developers can include it by default, as ubuntu does if I’m not mistaken.
IANAGU, but what if the user removes a menu item by mistake? Is there any way to undo that?
>IANAGU, but what if the user removes a menu item by mistake? Is there any way to undo that?
Yes. All apps that have a proper .desktop file appear in the editor. Next to the name of the app, there’s a tick-box. Un-selecting the app in the editor only removes the entry from the users menu. It doesn’t remove it from the editor and it doesn’t remove the .desktop file.
If the user un-selects the app in the editor, intentionally or by mistake, and, later, wants to return it to his/her menu view, they need only to re-select it in the editor.
Nonsense. It has been the plan from the beginning to only offer the required amount of functionality. Adding items is not required, because you should never need it if applications are not broken.
Then what is the point of having such menu editor? I understand that the average user merely need to hide and move menu entries, but you should also think about the slightly above average user that might need these functionalities. At worst, he could enable an obscure entry in GConf.
Getting another menu editor is barely a solution. Having two programs that pratically do the same thing is bloat.
If you need to fix broken applications and if you really want to make them appear in your menu…
Though I am a GNOME Zealot, I agree this sort of functionality would be appreciated…
Ok, changed my mind. Better to enforce standards..
😛
Because Gnome is a platform not a distribution. Complain to your distributor.
This to me show one of the serious flaws in Open Source development. Developers typically only work on what they think is fun and intresting rather than boring little things such as the menu editor.
If you need it so bad, why you don’t do it yourself instead of bashing like a baby. The code is open, take your favorite editor and start coding. Go and submit patch.
IMO, the serious flaw in OSS development is people like you.
6 months? Try 3 years, as that is approximately how long the 2.0 series of GNOME has been about. A decent solution should have existed in 2.0, not a half-assed on 5 (!) releases down the track. Yes, I know it’s free software, so we’re not allowed to whine, but where’s the accountability?
Hey, should have existed? Why? Where is it written? Oh, I forgot all of you trolls paid for that. Don’t you?
One of the advantages of the free software in general is the oportunity to change what you dislike, and adapt it to your needs. Most of the times you are receiving a high quality software for free. You don’t pay. So, you can’t just come and tell ‘it should, it should’.
Your complains should be better placed in a gnome mailing list, with your comments _and_ arguments. That’s what free software is all about. If you code, you can dot it. If you don’t push for the things you want to see.
But I don’t see any point in reply to a Gnome announcment that way. What I see as good, are comments based on arguments, and when I say arguments I don’t mean ‘personal reasons’.
I wonder if you trolls are as good as you say. So, why don’t colaborate? It’s much easier to just come and tell bad things, than help.
My god, I forgot you paid. And that you have MUCH better coding skill than gnome hackers. The problem is: you have only coded hello worlds.
Well, actually I have coded more than “hello worlds” but admittedly poorly. I don’t deny that – I’m not a programmer and I don’t pretend to be one. All you did was break out the usual “code it yourself argument”.
You also get me wrong: I love GNOME and use it happily, but it does have it’s flaws. The fact the 2.0 series have existed for 3 years without a proper menu editing solution is appalling. Would I be calling Microsoft out if they shipped Windows without a menu editor? You bet I would and so would you.
I’ll say it again: 2.0 should not have shipped without a decent menu-editing solution, let alone 2.2, 2.4 and so on. The GNOME team have let themselves down badly on this front.
Great article, focusing on important details I did not find anywhere else (e.g. how to open a terminal in nautilus). However, I am pretty sure the “open terminal here” feature has not been removed in this release (it was already absent).
That’s one of those KDE features. Probably not popular enough for GNOME or somethin.
Yeah, and I bet the day GNOME puts the feature in, it will be like — Oooh look at this cool feature! Now GNOME is the BEST KDe out there.
Seriously, its a case of obfuscating the past — George Orwell style, IMO. KDE has implemented each and every feature that GNOME has first but somehow it always gets more “media attention” once GNOME implements it, partial or otherwise.
The old navigation text input box is actually available as a preference in gconf/apps/nautilus/preferences/always_use_location_entry.
The new path bar sure looks nicer IMO. It’s sometimes more convinient, but sometimes not.
The thing I missed most was getting a terminal by right clicking, but an apt-get nautilus-open-terminal solves that problem.
GConf keys are only meant for power users, normal users on an enterprise environment might not even have access to the gconf gui. What I wanted is a real preference choice of which to use as default, and then interchange between them using Control+L as it currently is. Right now, not even the preference exists, but after you click Control+L and go to the input box you CAN’T go back to the path navigation on the same window without reloading a new window.
>apt-get nautilus-open-terminal solves that problem.
This is only for users with a debian or fedora though. FreeBSD or smaller Linux distro users won’t be as lucky. IMHO, the problem here is not the absence of “open terminal” but the fact that the Nautilus developers haven’t capitalized yet on the “Actions/Plugins/Scripts” power and instead of shipping some scripts/plugins by default (one of them could be the “open terminal on the current directory”) they are downplay them and hiding them, literally.
“but after you click Control+L and go to the input box you CAN’T go back to the path navigation on the same window without reloading a new window.”
Press escape. Yes, there should be a “close” button next to “Location”, but the most obvious key shortcut works.
In addition to a little “x” beside the location bar, I’d also like to see the location bar open up when you type “/” in the main nautilus window, much as you do with the file selector.
To open a terminal anywhere, put this in an executable .sh script script in your nautilus-scripts:
exec gnome-terminal
That will open a terminal in the directory you are viewing in the nautilus window.
You can also open a r00t terminal like this:
exec gnome-terminal -e su
Does anyone know whether session management finally works properly?
Anyways, I think I’ll continue to use KDE at least until Rhythmbox provides an (easy) way to edit ID3 tags and rename files and folders according to those tags.
And isn’t it a little bit too over-enthousiastic with its mentioning that Gnome would have nothing to fear from KDE if it had a little more enthousasm, better development tools, more and better documentation, a very good API, …
I mean, I could also write that KDE is the best desktop, and that it has nothing to fear from Gnome if they improve usability enough. Both are things that aren’t done in one afternoon.
Yay! Eugenia is back.
I have to agree with one thing. GNOME documentation sucks! Developer docs that is.
/me looks away from gnomevfs
Don’t get me wrong. The APIs are great and as powerful as anything you’d see on any other platform. But it took me days to figure out how asynchronous operations actually works with gnomevfs. Days to figure out how gconf actually works. Do I need to restart gconf after installing schema files? And I still have no bloody clue how to, when to, and if to use most of the libgnome libraries. Hacking on GNOME is no fun. It’s tedious and you spend weeks just figuring out how things should work. When they do work though, it rocks.
With respect to RAD. Use Python, PyGTK, GNOME Python and Gazpacho. That’s all you’ll ever need for RAD. Anyway good review overall.
I have to agree with one thing. GNOME documentation sucks! Developer docs that is
I agree too, though they are improving, as they are more and more auto-generated.
Still, the problem is that tutorials and howtos are not maintained. They still are usable because Gnome has backward compatibility until 2.0, but if you remove all deprecated symbols, nearly all the docs are obsolete (except API reference docs).
But it took me days to figure out how asynchronous operations actually works with gnomevfs
Look, I’m no genius, I’m not even programming regularly, but I found in, say 5 minutes, a recent example on how to do that (and I was not even searching for that).
Days to figure out how gconf actually works
It took me minutes … I found all the docs I needed. I’m trying to updating some of my old Gnome apps (that still works, but they are Gtk 2.0 apps) and so, I started learning recent Gnome and KDE. The most difficulties I had till now, is avoiding all the deprecated stuff, and I still could use GConf in less than an hour.
Do I need to restart gconf after installing schema files?
Have nothing to do with programming, but no you don’t.
And I still have no bloody clue how to, when to, and if to use most of the libgnome libraries
Had nearly no problem with that. The only problem I had is that all these are marked deprecated (in the docs, not in the code), but most still have no equivalent. When equivalents are available, it’s written in the docs.
Hacking on GNOME is no fun. It’s tedious and you spend weeks just figuring out how things should work. When they do work though, it rocks.
I disagree, I have a lot of fun hacking on Gnome. At start, I agree that it is more tedious than it should, a book on Gnome 2.12+ development is long overdue. But once you grasped how it works, you develop pretty fast with it. I’m still in the discovering phase, and I’ve not used GnomeVFS yet (seems to be the hardest part), so perhaps I will change my mind soon. But even as I saw why GnomeApp is a mess and why most of libgnome{,ui} need to go, it’s not difficult to grasp. My secret is that I use the DISABLE_DEPRECATED flags, so I catch every obsolete code very fast.
With respect to RAD. Use Python, PyGTK, GNOME Python and Gazpacho. That’s all you’ll ever need for RAD. Anyway good review overall.
Well, I still dislike python, because to this day, Gnome python apps still have memory leaks (I use mostly bittorrent) though it’s improving. Anyway, in my way back to Gnome and KDE devs, I’m starting with emacs/vi for Gnome, will be continuing with Anjuta (which I like very much, but I removed old Anjuta 1, and Anjuta 2 is still to buggy to even start a project, perhaps I will be able to help once I master more of Gnome 2.1x dev) for Gnomemm and finally, will use KDevelop when I will be on to KDE dev.
>> Do I need to restart gconf after installing schema files?
> Have nothing to do with programming, but no you don’t.
Actually you do have to restart gconfd or new schema files will not be picked up.
gconftool-2 –shutdown
or just kill the process. Failing to do so will mean apps will not get the default values specified when they read the keys.
Actually you do have to restart gconfd or new schema files will not be picked up
You can explicitely load them in your app though, that’s what I planned to do anyway, at initialisation.
gconftool-2 –shutdown or just kill the process. Failing to do so will mean apps will not get the default values specified when they read the keys
That should be a bug … Perhaps related to the cache. I suppose that’s one big architectural problem of GConf if it can’t be fixed. Now, with latest kernel using inotify, and latest GConf using it too if it is available in kernel, I suppose this can be overcome.
Well, make a change and colaborate with docs about what you learned 😉
I tried out the LiveCD for a few hours and overall was absolutely impressed. I’m not as hardcore as you guys but I try and check out every 4th release or so from Gnome and the polish and consistency across software packages was such a nice touch. Even little details like nicely animated cursors (I know, that’s been there forever) just really made everything feel nice.
The new LNF is fantastic to say the least. Great work all around.
http://www.sacredchao.net/quodlibet/
Gnome 2.12 is the best X11 DE there is.
What does that make KDE? Second best?
I wouldn’t go picking favorites, if I were you, unless you want to start a flamewar.
I love how you insist this is a flame. It’d give more respect if you quoted the full sentence.
“But having used both, as a normal user, I still prefer Gnome over any other X11 DE.”
Now let’s break this down. “But having used both.” meaning the experience is there with both of the Desktop Environments that are being discussed here, KDE and Gnome. “as a normal user” this implying someone who can sit down and do their work, whether that’s browsing the net, writing an article or email. “I still prefer Gnome over any other X11 DE” Now, notice that it wasn’t just against KDE, but a preference over all other X11 DEs.
What’s wrong with picking favorites? Just because I like Cinderella more than I like Guns and Roses, doesn’t mean that I’m a bad person, or that I shouldn’t write an article on how I prefer the sound of Tom Keifer’s voice better than the sound of Axl Rose.
It sounds to me like you’re just an idiot who is trying to start a flamewar more than anything. So just chill out and take what is meant by that sentence. I prefer Gnome over KDE too, for my own reasons. Does that mean I’m trying to start a flamewar?
Hey Eugenia… cool to see you’re back.
The article is nice. I don’t agree much about the “missing big new features” complain, though. I think it’s good that Gnome is focusing so much in the small details, and, also, there is some heavy work going on in other areas – such as implementing Cairo (yes, Gtk and Gnome are different projects, but we all know how they’re close to each other and how there are developers working on both projects at the same time).
One small thing i miss a lot in Gnome: an easy way to browse the file-system as root. Everytime i need to do that, i have to open a terminal, which sucks. There should be some way to right-click the folder, type the root password, and browse the folder as root.
‘One small thing i miss a lot in Gnome: an easy way to browse the file-system as root. Everytime i need to do that, i have to open a terminal, which sucks. There should be some way to right-click the folder, type the root password, and browse the folder as root.’
Try this script:
#!/bin/bash
# opens a root-enabled instance of a nautilus window in selected location
# requires sudo priviledges and gksudo, which may involve security risks.
#Install in your ~/.gnome2/nautilus-scripts directory.
foo=`gksudo -u root -k -m “enter your password for nautilus root access” /bin/echo “got r00t?”`
sudo nautilus –no-desktop $NAUTILUS_SCRIPT_CURRENT_URI
Most of the installs of Gnome I’ve used (currently Debian Unstable with Gnome 2.10) has an option under Applications -> System Tools -> Run as different user.
This will bring up a dialog box for user and program.
Adding this sort of script manually would be beyond the casual user’s abilities (although arguably the casual user should not need root access), but points to a more general issue to resolve with GNOME.
I agree with the GNOME philosophy of keeping the desktop as simple as possible, not providing feature bloat and especially not hacks to overcome other broken apps (eg: adding menu items).
However, I think there’s a case for a ‘gnome-extras’, where a lot of these items, scripts, apps etc that don’t fit in with the GNOME philosophy can be included. That way the base desktop can be customised easily to meet different user’s requirements without bloating and obfuscating the base release.
Distro’s targeting different groups of users might decide to include certain things from this gnome-extras section by default, saving the end-user from having to do so.
gksudo nuatilus
😉
Arr! That Nautilus be alot like Thunar now, it be it be. Arr!
It’s that we invented the look&feel for Thunar. So Thunar is probably a pirate too.
That should read: It’s not that we invented…
I must agree in that Nautilus Scripts are to underrated, why ain’t any distro using it? this is one of the greatest potentials of Nautilus and is barely used, Nautilus should come with at least 2 or 3 scripts by default than can do something usefull.
Another underated feature has to be the documents Templates, its so easy to create one in GNOME comparing it to Windows, and again, distros are not using it, if a distro includes OpenOffice then why not include a Template of an empty document? or a template of at least a text file?
My 2 cents.
Well said.
I must agree in that Nautilus Scripts are to underrated, why ain’t any distro using it? this is one of the greatest potentials of Nautilus and is barely used, Nautilus should come with at least 2 or 3 scripts by default than can do something usefull.
If a feature is generally useful, then it should be implemented in a more integrated way. Scripts are sub-optimal for this. What they are good for is to add features that are very specific to what a user wants to do, but no distribution can foresee this.
Another underated feature has to be the documents Templates, its so easy to create one in GNOME comparing it to Windows, and again, distros are not using it, if a distro includes OpenOffice then why not include a Template of an empty document? or a template of at least a text file?
Because templates are specifically not designed for creating empty documents. They are not good for this because either you have to leave out most document types or clutter the menu with dozens of entries. What they are meant for is for users to easily create their own templates for documents they often modify.
What I would like to see would be a generic and powerful way to create new documents of any type. That would be a required feature to make the document oriented workflow generally useful.
gnome is the worse desktop in the story
IMHO, Gnome’s going to the right direction… but still lacks some basic funcionality… to name one, the filemanager… It’s pretty easy to know how to use it, wich is a good thing, but doesn’t mean it’s that good… There’s not evolutionary learning in the file browser, what you see is all it can do. The reason seems to be personal taste of developers (as the spatial browsing, that’s very sane, but don’t look like a good solution for unixes with hundreds of basic system files… it’s ok for browsing your small music and video collection, some documents, but for anything beyond that, it’s a pain…), constant changes in GTK+ widgets (the shine new ones get ported to the file manager pretty fast) and probably many other ones I can’t remember right now and several ones I don’t know…
By comparition, try list a folder with a hundred other folders in Windows Explorer, it won’t update the screen every milisecond chaging the itens of place everytime it discovery a new folder in this hundred ones… thy use the “back” button; you’ll return to the same point you was in the last folder, and not to the top of the list of folders again.
Let’s talk about the location bar in Nautilus… it’s pretty, it’s sane and easy to undestand… but how can it make my work faster? I’m not talking about going back to the old path typing, I’m talking about how can we set up an evolutionary approch in the location bar? Do I really to double click it? Can’t I just click a path level and start typing to the location I want?
There’s no similar in Windows yet (just in Windows Vista, this behavios has been displayed a long ago and exists in Beta version, but I have just looked screenshots and not used the real thing to talk about…), but as an example, let me mention the Windows right-click drag’n drop. It’s something that won’t limit any new user to do anything. it’s something that it’s there, to be used as long you know it… and know what? It’s a LOT intuitive after you tried it (like learning to ride a bicicle!) and a real timesaver… non obstrutive pop-ups… it’s safe (if the user don’t know exactly what the action will do, the right click drag’n drop show him/her the options before doing anything… or nothing at all!).
I’m pretty sure that similar behaviors can be built to Gnome… making it easy AND powerfull. Instead of choosing how the user should do something, leting them choose between some sane behaviors… logical ones like the example.
I’m not going a lot more in deep details as I still have lots of things to do today, but I think that’s enough to get the idead of what I’m talking about (even with this terrible engRish…)…
it’s safe (if the user don’t know exactly what the action will do, the right click drag’n drop show him/her the options before doing anything… or nothing at all!).
Try middle click drag’n drop in Gnome, you might like it.
Well, it _clearly looks_ old and languid…
😀
I like gnome a lot (except nautilus) but decided not using it because it’s dog slow at rendering the desktop and consume too much memory for what it does and the machine becomes sluggish after 24h or so…KDE is a lot better in those area + konqueror is a better file manager IMHO for large directories.
Konqueror is an infinitely better file manager…. Sometimes I sort of with gnome would give up on this silly file manager notion (but that’s cause I stopped using file managers after starting to use Gnome)…
What irritates me most is the new file selector though (from 2.6). Please oh please see in your finite wisdom (sic) to give me a way to TYPE INTO THE BLOODY THING! Gtk went from the best file selector to the worst inside one release…
You can press ctrl-l in the file selector to type.
well, personally I can’t stand konqueror and all its icons, bar, menus an widgets all over the window, and I hated the old gtk+ file-selector while I consider very satisfying the “new” one… 1-1
please, remember that you’re personal opinions are not an universal measure of things
> well, personally I can’t stand konqueror and all its
> icons, bar, menus an widgets all over the window
I only see the menu at the top of the window as well as the iconbar having well arranged items on it that you can disable in case you dislike them. What’s wrong with that ?
> please, remember that you’re personal opinions are not
> an universal measure of things
Yours is ?
> give me a way to TYPE INTO THE BLOODY THING!
It exists. You just have to try it.
Type the name of the file to jump to the file. Keep typing to select the exact file.
Or press / to type the full path into the location dialog, seeing a drop down list of possible completions along the way.
I don’t see how the sequence of key presses is much different to typing into a terminal, or the old file manager.
By the way, Nautilus has great keyboard navigation too.
I tried Gnome 2.12 yesterday and I was not impressed at all. Like alot of people, I was hoping/expecting major changes in this release. But Gnome failed again to convince me that it was ready for intensive desktop usage. In fact, I was concerned about:
1- Performance
2- Look
3- Feel
— Performance —
The latest GTK+Gnome combo doesn’t do better than the older versions. After hearing so much good things about Gnome 2.12 on osnews-like sites, I was expecting a little more than this. There’s absolutely no performance improvement in GTK and Gnome. GTK is still a pig and Gnome follows the tradition as usual. I think they should focus on the issue a little bit more for the next release. I would make it top priority.
— Look —
Well even with a new default theme, Gnome hasn’t changed a bit. Don’t get me wrong; I don’t think Gnome looks bad but there are many things that could be better, mainly in GTK. In fact, I never really liked GTK controls. They are too big and they don’t look like controls I’m used to see. They need to be smaller, more standard (they look too flat) and finally more robust. It would improve the whole user experience alot if they could fix that. Also, the text should be smaller by default and more clear. I tried fixing the issue by recompiling freetype2 with the bytecoder but I didn’t help much. I really don’t know how this could be fixed and the Gnome font config utility really annoys me. It doesn’t let me config my fonts like I would want to. I simply can’t get good result with it.
— Feel —
Let’s talk a little bit more about GTK controls. I think that most of the time they don’t give a good feeling to the user. Mainly the buttons, the editboxes and the list/icon/detail views. There are problems with those that can really ruin the whole Gnome experience. You probably all have experienced weird Nautilus behaviors before. Icon view doesn’t display stuff properly and the keyboard interface for list/detail view is sometimes unreliable. More weird behaviors happen with buttons and editboxes as well. Some of you would tell me it’s not a problem with Gnome but with GTK but I see them as a whole. I won’t close my eyes on Gnome problems just because they are inherited from GTK.
So that’s my opinion: I think Gnome is overrated. For those who want to know if I’m a KDE fanboy I’m not. Indeed, I think KDE is overrated as well. Both need more code profiling and interface polishing. Unlike others, I don’t expect a load of features but I only expect things to work as they are supposed to.
Performance: Actually, it should be worse.
Look: Increase your screen resolution.
Clearlooks is amazing… It’s reliable, it’s fast, it’s pretty, and it doesn’t give me a headache.
Feel: I’m not sure if nautilus uses gtkiconview now, their used to be a hacked up icon view it used inside gnomelibs. I think iconview was added in 2.4 or 2.6 of gtk?
Honestly, you haven’t named a problem. “This doesn’t work how I think it should” is not a problem. “This works this way and it should work that way” is. Please, be less ridiculously general.
Why do you say they need more profiling? Do you believe there is a small subset of functions wherein the performance issue lies? You don’t think it has anything to do with the architectures and you don’t believe that the maintainers are aware of it?
I find both interfaces pretty polished… Sometimes polished to the point of either making things too complicated or making features dissappear. How are they lacking in polish?
Seriously though. What in the world do the buttons do that’s wierd?! They’re pretty simple compared to treeview, iconview, and combobox and those sorts of things which gtk may do differently; what do buttons do oddly?
Performance:
Gnome feels much faster with video hardware that supports acceleration of the Render extension, it also is noticably faster when using a compositing manager, of course this results in more instability of X.
Look:
Try adjusting your DPI setting to be true to your monitor/resolution, and after that adjust your font sizes. (I prefer 11pt fonts). Also there are themes that make widgets smaller as this is typically adjustable in the engine.
Feel:
I’ve not experienced many weird behaviours, perhaps you could let us know what they are? A bug is a bug, and should get reported.
Gnome feels much faster with video hardware that supports acceleration of the Render extension
Wonderful. So Gnome needs hardware acceleration to get acceptable performance? Hardware accelerated XRender requires supported drivers (of which there are a selection of one) and it is notoriously buggy to the point where it isn’t an option.
As was pointed out in another thread, the Glitz/OpenGL back-end for GTK/Cairo is not turned on for a reason. That reason is because to get any benefit out of it you really do need a solid, reliable hardware accelerated OpenGL implementation. Since the only manufacturer producing good enough drivers is nVidia, and they are closed source (and not always 100%), relying on one company’s drivers simply to get your GUI up and running is simply not acceptable. You know, people promote desktop Linux as being able to run on older hardware……
Telling people to use hardware acceleration is not an excuse for what they’re seeing.
it also is noticably faster when using a compositing manager, of course this results in more instability of X.
Well that’s not really an option, is it?
XRenderAccel requires very little support. Both major vendors drivers should work fine with it. Compositing requires a bit more..
It, like every program ever written, requires fairly modern hardware. It feels fine with nv and a duron 1GHz, and the same on a 700 celeron with trident card.
“Telling people to use hardware acceleration is not an excuse for what they’re seeing.”
Would you rather have highly flexible and powerful applications which look good or ugly ones with a weak API that run blazingly fast?
If you’ve found performance problems in gnome or gtk, please feel free to use your time to fix them and send in patches. Otherwise, complain about serious problems not “I can just barely see the app draw a few things.”
> Would you rather have highly flexible and powerful applications which look good or ugly ones with a weak API that run blazingly fast?
How about both? Oh, wait … this is Linux/GNOME. Nevermind.
As for sending in patches … yeah, don’t be silly. When someone has a valid complaint about a piece of open-source software, all the OSS zealots scream back “Well patch it yourself!” while in a froth. Well maybe 99% of users are incapable of fixing up the code? Maybe that’s your job as developers?
That kind of attitude isn’t going to propel your worthless OSS junk any further.
XRenderAccel is NOT supported by the ATI closed drivers and cards from the R300 series and up have no hardware acceleration from the open source drivers. NVidia is the only major card maker that has a decent set of drivers for Linux.
Relying in Render acceleration to get decent speed is a big mistake from the GNOME developers because only NVidia cards will have it.
I should say that I really really regret the lack of support for XRenderAccel from the ATI fglrx driver.
As an ATI user, I am however not stuck with it. There is a alternative, the radeon driver that *should* work with XRender. I must say I never tested it, because I need performance …. for games. I just cry I choosed a laptop with ATI
.
BUT I DO NOT LIKE YOUR DEBATE ON GNOME. Come on… GNOME. It managed a lot of stuff concerning interactions between aps, and that’s what a “desktop” needs. It might be slower than KDE, I might be more beautifull, it might be less.
Do you need a Desktop? I am not alone in this room to NOT use gnome desktop, but to use a lot of the gnome-related apps: Evince, Eog, Gimp, the gonme-toolbar, various gnome-utils…. etc…. etc Everything under FVWM
Yes I like Gnome and Gnome developer and I thanks them a lot for the nice app and the extreme modularity of it all ! By comparison most of KDE tools are too integrated to be used without KDE, other philosophy.
To me and many other Gnome let you the choice, above all. Speed issue with Metacity? Try Fvwm, Enlightenment, Sawfish… so many Gnome2 compatibles WM. You do not like nautilus, I recommand you RoxFiler … etc.. I have many exemples. I am a guy that like to have the choice, like my distro gives me much liberty (debian
).
You can’t blame people for the thinks that they should do to be nice to you while it take a lot of their time and none of yours, that’s why you often see fed up developers posting “do it your self” of course. On the other hand, developers are very enthousiasts people (I am one too) and like to convience people that their apps can fullfil your dreams, which is never the case.
Open source gives you tools, you are free to use them in any configuration you want. Thanks to the gnome team for the work done so far.
As an ATI user, I am however not stuck with it. There is a alternative, the radeon driver that *should* work with XRender. I must say I never tested it, because I need performance …. for games. I just cry I choosed a laptop with ATI
.
Your logic is pretty flawed… You need performance for games, yet you run Linux. Why not just get an XBOX or PS2 and use Linux for what it’s meant… Downloading games for XBOX and PS2
——————————————————
Please keep in mind that downloading is illegal, and
stuff. Don’t do it. It was a joke.
I noticed you incited me to steal some majors in you answer ^^ But I would have prefered: rob a console and buy the game you want… Pirating games sadly put penalty over the games development studio and the market is very difficult for such companies.
Anyway that’s not the topic…
XRenderAccel requires very little support. Both major vendors drivers should work fine with it.
What about those people with graphics cards not by the two major vendors (which is just about everyone)?
Would you rather have highly flexible and powerful applications which look good or ugly ones with a weak API that run blazingly fast?
That depends which way round your putting that, because both sides of the coin there are wrong. I’d rather have efficient applications work on the widest variety of hardware possible so people could actually use an open source desktop. I think you’re missing the goal here.
You can of course use a simply theme that runs extremely fast, like themes which use the mist engine, and opt for bitmap (png) icons over vector icons.
Heavier themes require better hardware, especially vector icons, and the brand new cairo based themes.
Performance:
Gnome feels much faster with video hardware that supports acceleration of the Render extension, it also is noticably faster when using a compositing manager, of course this results in more instability of X.
Its funny that you say that, because its Gnome (not XFCE or KDE) that refuses to add a decent composite manager built into its window manager (metacity). All the other major DE’s has this.
Because of this, I plan to move to KDE when 3.5 comes (aka with a more stable compmgr) despite using Gnome for a year. I’m working now to make KDE look more like Gnome now. Gnome’s stance on hardware acceration sucks, I wish they didn’t punish those of us with Nvidia cards just because our drivers are closed and because no other cards can do it yet.
Your point is a very weak one.
Actually, kwin’s compositor is so bad it’s unusable.. Xfwm4’s is awesome, it almost works. But kwin’s is just baaaad (or at least the 3.4.0 one was).
Also, xapp’s will composite anything. Gnome is right to not include one; it’d just be a lot of extra list traffic like this:
“my compositor doesn’t work”
“unsupported, shutup.”
“are you gonna fix it?”
“unsupported, shutup.”
“why do you tell me to shutup?”
“rtfm”
“but it’s in there, so isn’t it supported?”
“NO, leave us alone already!”
Actually, kwin’s compositor is so bad it’s unusable.. Xfwm4’s is awesome, it almost works. But kwin’s is just baaaad (or at least the 3.4.0 one was).
I think it was a direct fork of the now dead xcompmgr. Thats why I plan to move to KDE in 3.5, when some of the bugs are worked out.
Gnome is right to not include one; it’d just be a lot of extra list traffic like this:
Well, if Gnome wants Metacity to continue to be a blight on the entire DE then I will not stand in their way. But I will say that an accerated desktop is about more than eye candy, and no Window Manager in existance needs compositing more than Metacity (its the only thing that makes the draw black crap all over your screen when minimizing “feature” tolerable).
Metacity has two compositing related branches. One is luminacity which is a testbed for all kind of OpenGL effects and the other is spiffifity, which is about improving the built in compositing manager. It will be available once it’s ready and everything is stable.
If you are looking for experimental eye candy, your best choice probably would be E17 anyway.
Metacity has two compositing related branches. One is luminacity which is a testbed for all kind of OpenGL effects and the other is spiffifity, which is about improving the built in compositing manager. It will be available once it’s ready and everything is stable.
Luminocity and spiffifity, or as I call them “the toy and the thing that fights xcompmgr when I want some effects.” As it is, spiffifity simply doesn’t work (it would have been better to fork xcompmgr like KDE and start with at least SOMETHING) and that was the reason it was left out of Breezy. Luminocity is its own project in which parts of it will be merged back into Metacity (before I die I hope). Problem is, Luminocity eats a LOT of resources when it is not hardware accerated and its very far from being usable.
Its obvious. The Gnome people want to wait for the Open Source Drivers (maybe just for the ATI 9200) to get up to speed before they include such things. I say this is stupid, because some of us Nvidia owners are willing to be early test subjects to help build the structure so that at the exact time when the drivers are ready the acceration will be ready. This is how KDE and XFCE are treating the subject of hardware acceration.
Instead, Gnome will wait and it will be up to six months behind in the Eye Candy department when KDE 4.0 comes out. I really like Gnome and gnome apps (more the QT stuff) but I think Gnome is making a mistake here. Getting it to first work on the best drivers availible (the closed Nvidia ones) will NOT make the whole thing dependent on closed drivers. It will just hammer everything out for when the Open Source world is ready.
If you are looking for experimental eye candy, your best choice probably would be E17 anyway.
I don’t care about the Eye Candy as much as the acceration. E17 lacks hardware acceration and is unexceptable to me at this point. It makes a big difference- its not all about Eye Candy.
Without xcompmgr turned on in Gnome, when my CPU is being maxed out and I move windows they leave behind a very ugly trail. When I minimize apps under the same condition, Metacity leaves blackness on my desktop for a second or two. With xcompmgr turned on, both of those problems go away.
I would just leave xcompmgr on but even in Breezy it fights with Gnome some (less than before though). Plus its a dead project- no new release since 2004. Too bad, the effects of it are awesome. Its like night and day….it would make Gnome a lot faster on old computers with Nvidia cards.
But it doesn’t matter. Gnome has made its choice. One again it will put principal before anything, even common sense. I will switch to KDE for 3.5 and leave unaccerated Gnome in my past.
As it is, spiffifity simply doesn’t work (it would have been better to fork xcompmgr like KDE and start with at least SOMETHING) and that was the reason it was left out of Breezy
The problem is that xcompmgr is as unusable as KDE kompmgr. You have to use all kind of hacks (depending on the setup) to make them work without crashing your entire machine. The only compositor that works reasonnably well is the one used by XFCE. Everything else is just instable, especially if you want to use OpenGL apps and XV videos.
And I use NVidia binary drivers, so I should know. They are still too unstable.
I think Gnome devs rely on EXA to accelerate things for the near term. XAA is really too old and unaccelerated.
Without xcompmgr turned on in Gnome, when my CPU is being maxed out and I move windows they leave behind a very ugly trail. When I minimize apps under the same condition, Metacity leaves blackness on my desktop for a second or two. With xcompmgr turned on, both of those problems go away.
Your setup has a problem, because I never experience any of this without using xcompmgr, even when my 2 CPUs are maxed out. I experience small jerkiness or slowness sometimes with CPU maxed out, which is irritating, but that’s all.
I would just leave xcompmgr on but even in Breezy it fights with Gnome some (less than before though)
I don’t know what you mean. At home, any compositing fights inside the card or inside the driver. If it was fighting Gnome, I would have no problem using it with XV or GL apps. For now, KDE 3.4.2 still will crash on start with any compositing on. If you have no acceleration without activating compositing, sth is really wrong with your setup. Compositing is not supposed to accelerate anything. With cairo, I know my Nuvola (vector icons) desktop is faster than before, but perhaps it is due to optimisations in GTK+.
I will switch to KDE for 3.5 and leave unaccerated Gnome in my past.
For that, you’ll have to hope that compositing works in KDE 3.5. In KDE 3.4.2, it still crashes everything here with a Ti4200 and latest NVidia drivers. For metacity, they disable the compositor by default, and tell you to activate it only for debugging purpose. I think they will improve it. As manufacturers probably won’t make a lot of dev to improve their cards, the work will have to be done on kernel DRM, XOrg components and DE compositors. DRM work is the more important part IMHO, as it will manage the state between XV, composite and GL apps.
The problem is that xcompmgr is as unusable as KDE kompmgr. You have to use all kind of hacks (depending on the setup) to make them work without crashing your entire machine. The only compositor that works reasonnably well is the one used by XFCE. Everything else is just instable, especially if you want to use OpenGL apps and XV videos.
And I use NVidia binary drivers, so I should know. They are still too unstable.
Honestly even XFCE’s crashes hardcore on me. The reason I still use Gnome with xcompmgr because I can easily turn it off and on when I need to do something that I CAN’T have crash. I just can’t wait for one of the DEs to release a compmgr stable enough I don’t need to do that anymore- which ever one does it first has me as a convert. From what I here it will be KDE 3.5. If this is not the case I will be the first to bitch about it.
I think Gnome devs rely on EXA to accelerate things for the near term. XAA is really too old and unaccelerated.
Gnome WILL rely on it, months after its released and KDE does…..Gnome will be fully accerated by it but probably more than a year from now.
Your setup has a problem, because I never experience any of this without using xcompmgr, even when my 2 CPUs are maxed out. I experience small jerkiness or slowness sometimes with CPU maxed out, which is irritating, but that’s all.
Seeing as how much I care about UI responsiveness, I bet the truth is I’m just more picky than you. When I use a Mac I don’t gasp at Expose and the drop shadows, I gasp when I move windows and the edge lines don’t break.
I don’t know what you mean. At home, any compositing fights inside the card or inside the driver. If it was fighting Gnome, I would have no problem using it with XV or GL apps.
1. run xcompmgr
2. try to log out in Gnome
3. see what I am talking about
If you have no acceleration without activating compositing, sth is really wrong with your setup. Compositing is not supposed to accelerate anything.
Composting allows my GPU to get in on drawing the desktop. This accerated EVERYTHING- all the things drawn like windows and whatnot. I know because I’m picky and I feel a huge speed difference when I use the
xcompmgr -a
command (the one without all the effects).
With cairo, I know my Nuvola (vector icons) desktop is faster than before, but perhaps it is due to optimisations in GTK+.
Cairo is not hardware accerated yet.
I agree about the big controls. This is what is the worst in Gnome. The second is slow GTK (maybe for someone who used only gnome it seems to be fast and highly resposive but for me (I use KDE on linux, but most of my time I work in windows) it is simply sluggish. And don’t try to convience me that it isn’t. This is the fact.
I agree about the big controls. This is what is the worst in Gnome
Isn’t this due to the HIG ? Apps can make icons the size they want, but the HIG has to be respected.
Anyway, you can use smaller fonts to scale down everything.
The second is slow GTK (maybe for someone who used only gnome it seems to be fast and highly resposive but for me (I use KDE on linux, but most of my time I work in windows) it is simply sluggish.
Stop contradicting yourself and comparing apples and oranges. If it feels fast and highly responsive when using only Gnome, then it is good enough, that’s what we want. It’s not a stupid speed contest like you imply.
Then, Windows shell has nowhere near the same functionalities as a Gnome (or KDE) desktop, so stop the nonsense.
Most of the thing Gnome (and KDE) are useful for to me are not even possible in Windows !! From start of session (sessions) to end (actually stops no matter what, even if with some delay), with a lot of things in between (on the fly language change, multiple language input methods everywhere, 3 simultaneous networked user desktops, shared sound between users, …).
About menu Editor in GNOME.
To be honest I’ve never needed to edit the menu, not even on Windows, is more handy to have a shortcut in the panel, the fact that GNOME uses 2 panels as default makes it easier.
BTW, drawers in Panels are handy too, you can make your own category with drawers and put shorcuts there, when you have something like this menu editing is not a as needed but if some users can’t live with it, they can always install one.
but as an example, let me mention the Windows right-click drag’n drop. It’s something that won’t limit any new user to do anything. it’s something that it’s there, to be used as long you know it… and know what? It’s a LOT intuitive after you tried it (like learning to ride a bicicle!) and a real timesaver… non obstrutive pop-ups… it’s safe (if the user don’t know exactly what the action will do, the right click drag’n drop show him/her the options before doing anything… or nothing at all!).
Actually, Windows’ right-drag does get in the way. Because of the right-drag thing, Windows can’t immediately display a right-click context menu on button press. It has to wait for the button release.
Also, you get the same functionality with middle-drag or Alt+drag in Nautilus.
Because of the right-drag thing, Windows can’t immediately display a right-click context menu on button press. It has to wait for the button release.
That’s how it should be! You have to give a way to the user change it’s mind before doing anything.
Also, middle mouse doesn’t look like a good solution with users emulating middle click…
…and we should not forget too that middle click usually does some other default action in most of applications (looks firefox and page scrooling and tab closure with middle click…), or are used for fast document scrolling (also, firefox for example)
…also, (almost forgot!) the middle click in MANY mouses today is the scroll wheel pressed… so, how can I not release the wheel and ALSO use it to scroll down (example) the screen and release the documents I want in the folder in the bottom of the scrolled screen? Do you see an evolution of ideas? Combining simple behaviors naturally without giving up any of them? It’s like typing, picking up the phone and still typing with the other hand (and probably getting information for pass on the phone…).
That’s how it should be! You have to give a way to the user change it’s mind before doing anything.
If you change your mind after opening a menu you close it. I don’t see your point here.
…and we should not forget too that middle click usually does some other default action in most of applications (looks firefox and page scrooling and tab closure with middle click…), or are used for fast document scrolling (also, firefox for example)
And right click doesn’t do anything in apps?
Just fyi, middle click pastes the last selection in X. It’s still not a problem, because one is a click and the other is a drag.
Of course the problem is that left-dragging does different things in different circumstances with only a tiny [+] icon as a notification, which confuses a lot of users initially.
I actually like KDE’s version. While a bit unexpected at first, it works out pretty well in general.
This is probably the most important feature that is still absent in Gnome:
http://bugzilla.gnome.org/show_bug.cgi?id=44767
It looks too much like WIndows. eww
It’s a bit unfair to the KDE developers to say they rely on Trolltech for all their documentation.
The KDE developers provide a significant amount of documentation themselves using Doxygen (see http://developer.kde.org/documentation/library/3.4-api/). Further, there is a good collection of tutorials, HOWTOs and even a book on http://developer.kde.org. Finally, there is a good doc bundle supplied with KDevelop, which includes a tutorial on developing a basic KDE application. With the exception of the books (free online copies of a KDE 2.0 book [now a bit outdated], a Qt3 book and a C++ book), all of this was developed by KDE volunteers.
KDE adds quite a bit of added value to Qt. If it wasn’t for the quality documentation, a lot of that wouldn’t get used.
Thanks to gnome linux are losing credibility
As one guy once said:
“Developers, developers, developers, ..!”
Other than that, I have to sing: *GNOME ROCKS*!
Is anyone using Garnome to try out Gnome? Garnome has always interested me but I have always assumes that it would be too difficult to figure out.
If you are using Garnome, can you tell me what you like about it? Does it give you the option of not building things like Evolution (for example)?
From the garnome FAQ:
3.10 GARNOME installs a package I don’t want, can I get rid of it?
Occasionally, a package is released that will not build on some systems, this can be due to a number of factors — including:
Your system may lack the tools to compile a package
Your system may be too old to compile a package
The package conflicts with a library already on your system
There is a maintainer bug in the package
The easiest solution to this problem is to remove the package directory from it’s meta-repository, eg:
rm -rf fifth-toe/rhythmbox
Would remove the Rhythmbox package from the optional fifth-toe repository
caution: If a package located in the platform/ or desktop/ directory will not compile, please consult the mailing list archives for a possible solution BEFORE removing it — as this action will probably damage the dependency checking that GARNOME uses to build a working installation.
Thank you so much. I missed that when I was looking it over.
This, to me, is the sort of issue that illustrates the mindset of the GNOME devs compared to the KDE devs.
With KDE, you have a fair amount of cruft accumulate due to incremental platform-building over many years, this tends to make the UI a little unwieldy at first glance, but in terms of functionality, provides an excellent and complete environment.
With GNOME, everyone seems eager to throw out everything after a year or so of development to focus on the next cool toys leaving the actual functionality of the desktop in disarray.
One only has to look at gedits lack of gnome-vfs support, the continuing lack of a menu editor and the introduction of ‘spatial’ mode followed by about 6 releases trying to patch up the incredibly awful flaws in its implementation to see that the GNOME project suffers from flawed vision, and some rather poor architectural decisions.
Compare Kate and Gedit side by side, or look at konqueror and nautilus, and the difference in capabilities between them is staggering, with the KDE apps making the GNOME apps look like half-assed toys.
Even Konsole vs GNOME-Terminal is eye-opening, with GNOME-Terminal using vastly more resources than Konsole for seemingly far less functionality.
And a previous poster is quite correct in pointing out that GNOME will soon all-but-require you to run a non-free system (i.e. NVidia drivers) in order to avoid glacial performance.
I used to be a big fan of GNOME, but no more. And no matter how many incremental releases get made with more slow, stupid eye candy, until the GNOME devs can find the time to address basic platform-API support within their apps and reduce the horrendous resource requirements, they have lost a user in me.
Yep, I agree with the whole content of your comment.
I use to be a GNOME fan, I left them with the spatial nautilus, and every time I try a new release I don’t regret leaving them.
Looking the way GNOME and other DEs progress doesn’t help too. That’s too bad, cause some things are good in GNOME, like the menu which is perfect (easily readable). I really hope that GNOME will try to focus on speed, memory usage and functionnality, rather that having debates no one cares (like Mono vs Java vs python) and trying to reinvent the way of browsing (spatial nautilus).
Please replace all occurences of the word “user” in the article to “corporate user”.
Seeing the way eye-candy is preferred by users on their desktop, GNOME is too stait-jacketed. With Sun, Novell, Redhat behind it primiarily, is is expected but it is important for the author to make this distinction.
I personally don’t work with GNOME unless its a linux box I have to work on at my office. At home, I cannot imagine myself using it. it is too ‘Big Brother’-ish IMO. Too much control on what you can do — and cannot. Can someone tell me, for instance, how I can change the color theme of my desktop without affecting other things like widgets??
>>>Adding items is not required
>>And WHO made the STUDY to really tell if it’s required or not???
>Is a study really necessary?
Not really, anyone not in denial and trying to defend a error would not need it, but for some it may have helped. It would have shown the real use for an menu editor would primarily be adding new entries and changing(editing) existing ones. Changing location or moving entries around would be the least used used functionality.
>if the app isn’t broken, the user wouldn’t need to add menu items.
For user in the real world this is not the case so handle it.
>Such as adding a launcher on the panel or desktop
The user wants it in the menu, deal with it.
>writing the app.desktop file and dropping it in to the correct directory
The user don’t want to learn the correct syntax for .desktop files or bother with their location. Compare the usability to something like 2 minutes with a GUI menu editor.
>the correct directory(generally /usr/share/applications).
For normal users, surely not. ~/.gnome/share/applications, more likely.
Doing things like adding a selfmade xdialog/normal script, small app or adding/changing a application start-up parameter are some typical task. And the user are not interested in mucking about with .desktop files, that’s why you have menu editors. A simple study of actual users would have told you so.
It would have shown the real use for an menu editor would primarily be adding new entries and changing(editing) existing ones
I sure would never asks you for a study, given that you know/are biased to the answer before ever starting anything.
>if the app isn’t broken, the user wouldn’t need to add menu items.
For user in the real world this is not the case so handle it.
No, users in the real world use distros, so the distro has to handle it, and that’s what they do. Your point is moot.
>Such as adding a launcher on the panel or desktop
The user wants it in the menu, deal with it.
No he doesn’t. I am a user and I don’t, so who are you to tell me I want ? The fact is you don’t know what the user want, a gnome app exists to overcome this problem, but you want to modify the base platform because that suits you better. But clearly, you are not an ordinary user. Every ordinary user I saw avoid the menu as much as they can, and use icons on their desktop or on the panel. Power users know how to install smeg.
>writing the app.desktop file and dropping it in to the correct directory
The user don’t want to learn the correct syntax for .desktop files or bother with their location. Compare the usability to something like 2 minutes with a GUI menu editor.
The user doesn’t have to !! The .desktop file is actually simpler to edit with gedit than any GUI. The GUI just puts a GUI around the content of the file, adding complexity, but reassuring people like you. It’s actually more tedious and longer to use a GUI for editing these than do it with a text editor.
Anyway, this is the distro’s duty.
>the correct directory(generally /usr/share/applications).
For normal users, surely not. ~/.gnome/share/applications, more likely.
For normal users, the default correct directory and standard one is <gnome prefix>/share/applications.
What you described is for user only prefs. You talk like you are alone to use the machine. We are several people on mine, and sure as hell, when an app is installed, creating a menu entry just for one user is NOT the way to go. There’s a reason for the standard.
Doing things like adding a selfmade xdialog/normal script, small app or adding/changing a application start-up parameter are some typical task
There are Gnome ways to create your own menu or icons to do that, but you refuse the Gnome way, you want to have the (broken) MS Windows way absolutely. You have the tools to do that, but still, the problem is you want this *in the platform*. For now, Gnome devs said no, can’t you accept that ? If the Gnome devs then realize they were wrong, you can be sure Smeg, once up to Gnome standards (HIG, …) will be integrated.
And the user are not interested in mucking about with .desktop files, that’s why you have menu editors
Strangely enough, menu editors muck about with .desktop files …
Ookaze
No he doesn’t. I am a user and I don’t, so who are you to tell me I want ? The fact is you don’t know what the user want, a gnome app exists to overcome this problem, but you want to modify the base platform because that suits you better. But clearly, you are not an ordinary user. Every ordinary user I saw avoid the menu as much as they can, and use icons on their desktop or on the panel. Power users know how to install smeg.
Sure, power users know how to install smeg, and ordinary users know how to use it. So clearly there is no problem making smeg the default application or adding the missing functionality to the existing lame version. Just saying that the functionality of SMEG wouldn’t be needed if all applications followed the standard isn’t good enough.
What about legacy applications, that was written before any menu standards was written. Users and sysadmins will need to add such applications to the gnome menu and a menu editor program should cater for that. A sysadmin may also want to change the order of the menu item is such that the most frequently used applications in the organization requires the least mouse movement to start.
One thing I’ve always wondered. Why is everything so huge? Compare a GNOME/Gtk+ menu to a KDE/Qt menu the former is much bigger, and it’s not just menus, buttons too. Icons can be bigger or smaller in KDE, as all KDE apps give you the option to adjust icon size among other things. The question is though, is this a GTK issue? or is it a Gnome issue?
This wasn’t intended as a flame war and a one word snswer would suffice.
It’s a design decision. Personally I prefer the relatively larger sizing of GNOME, but arguing about that is pretty silly considering that it almost entirely depends on screen resolution. The solution is to make the interface entirely scalable (like fonts already are), then we can argue about the most tasteful relative sizes.
Cairo is one step into this direction.
In any case you can’t say smaller = better, it’s always a tradeoff. For example, larger buttons are faster to click on and thus more efficient (Fitt’s law). It would be a mistake to think that advanced users aren’t affected by this, just because they are good at mouse control.
It’s a design decision. Personally I prefer the relatively larger sizing of GNOME, but arguing about that is pretty silly considering that it almost entirely depends on screen resolution. The solution is to make the interface entirely scalable (like fonts already are), then we can argue about the most tasteful relative sizes.
Cairo is one step into this direction.
In any case you can’t say smaller = better, it’s always a tradeoff. For example, larger buttons are faster to click on and thus more efficient (Fitt’s law). It would be a mistake to think that advanced users aren’t affected by this, just because they are good at mouse control.
The problem that I have with this assertion is that big widgets works fine for really simple applications as browsers, e-mail clients, RSS readers and such.
Throw something more complicated like a 3D modeller, non linear video editor, CAD program or something like that, which often has to show several options to the user at the same time for the sake of productivity and you´ll run out of luck. It simply doesn´t work for these types of applications.
GNOME has been leading this annoying trend on OSS of oversimplification of everything, even when it comes in the way of the original purpose of a said program as if requiring a user to learn to use something was a capital sin. I don´t mind a browser simple to use but I can´t see big icons working on Blender, for starters (And no… Blender has NOT a poor UI nor is this an OSS flaw. Any 3D application worth its salt has a daunting UI, like Lightwave 3D or Maya, and (god forbid!) actually require their users to learn something before start to use them.)
I´d appreciate even more GNOME developers efforts to simplify the interface as long as they kept the possibility to power users to take full advantage of the software, allowing them to adjust the software as they see fit after learning. The problem here is that the user can outgrow the limits imposed by the the GNOME DE in a very short timeframe and after that they´re screwed. I, for one, feel more constrained within GNOME than on Windows.
That alone, besides the eye candy factor, makes me prefer KDE even if I do know that it could use a little bit HIG on its default state. The power to make it suit my workflow and my preferences for the price of 30 minutes tweaking it is more than worth it.
DeadFish Man
Gnome, I think. Because GTK apps look more or less normal when run in KDE, so it could be the Window Managers (kwin vs. metacity- btw, I thought Gnome used Sawfish, was that 1.x? I don’t recall checking recently), and in that case it wouldn’t be as toolkit-related.
I wonder why Daniel Borgman and ralph are speaking on behalf of everyone or specially GNOME as in this case. I am using GNOME too and even I consider many things not as perfect as many others seem to be saying and writing here. There is no need for you to play the ‘GNOME task force’ here on this site. Simply accept the comments given by people. If they disagree with something then you can be sure that the last thing they want to hear is your defense or your explaination why this and that is so good and how much wrong they are because of their opinion. It’s really sickening.
I sure would never asks you for a study, given that you know/are biased to the answer before ever starting anything.
Not really a need to do a formal study in this case, I have already seen it by interacting with real users. You should try it too sometime.
No, users in the real world use distros, so the distro has to handle it
Ok, it’s clearly broken but the distros fix it so Gnome don’t have to. Fair enough. Mandriva and Ubuntu have their own tool In Suse you always have Yast, and I’d guess the rest have a way too.
>The user wants it in the menu
No he doesn’t. I am a user and I don’t,
Wohoo, Great user survey.
a gnome app exists to overcome this problem, but you want to modify the base platform because that suits you better
The application menu are a centralized place to launch applications from, clearly it’s more user friendly to not let the user install application launchers there. And rather force them to install them in other places, since it gives a more consistent desktop and better usability.
The .desktop file is actually simpler to edit with gedit than any GUI.
In that case the GUI is severely broken, as it’s should be even simpler than the gedit GUI. Otherwise this statement is simply ridiculous.
What you described is for user only prefs.
I was talking about users, not administrators. Or personal programs or special settings.
creating a menu entry just for one user is NOT the way to go. There’s a reason for the standard.
Exactly, and that’s the reason the standard has user only prefs. Plenty of real world reasons for it too.
There are Gnome ways to create your own menu or icons to do that, but you refuse the Gnome way
Same as above, wohoo great usability. Why don’t you remove the menu altogether since the user should not bother with it. Or perhaps what you call the Gnome way are broken. Besides hiding behind the O’Holy HIG does not make it any more usable, and nowhere in the HIG does it state “thou shall not be able to add or edit entries in thy menu, with a easy to use GUI”.
Strangely enough, menu editors muck about with .desktop files
Yes, you have a nice and easy GUI and the application does all the mucking for you, so you as a users don’t have to. Thanks for making my point clearer.
Not really a need to do a formal study in this case, I have already seen it by interacting with real users. You should try it too sometime
Strangely enough, that’s exactly what I have done. And some users I see every day (wife). And their behaviour is nothing like what you describe.
Ok, it’s clearly broken but the distros fix it so Gnome don’t have to. Fair enough. Mandriva and Ubuntu have their own tool In Suse you always have Yast, and I’d guess the rest have a way too.
Did you try to change subject on purpose ? The APPS are broken, so it is NOT the task of Gnome to be a workaround to broken app. Duty of Gnome is to enforce the standard. Distros fix the broken apps. What disturbs you in that ?
The application menu are a centralized place to launch applications from, clearly it’s more user friendly to not let the user install application launchers there. And rather force them to install them in other places, since it gives a more consistent desktop and better usability
The application menu is a centralized place for *automatically make a link to your installed applications*. Gnome has several ways to launch applications, not only the menu. In case you did not notice, most applications in the menu are installed automatically !! Whereas most applications on your task bar are added by the user. So YES it is more user friendly to not let the user install application launchers there, so he can easily make a difference between original launcher and custom ones. So yes, it is more consistent and has better usability.
In that case the GUI is severely broken, as it’s should be even simpler than the gedit GUI. Otherwise this statement is simply ridiculous.
What you say is ridiculous ! So you assume that in EVERY CASE, a good GUI is more efficient than editing a config file ? And you have the guts to say sth as stupid as that ? In my world, someone knowledgeable enough will always be faster editing config files by hand than with a GUI, except if these files are complex XML things. Specially in this case, creating the .desktop file or adding entries for your language is clearly faster with gedit (or faster with vi) than with the GUI, and no, it’s not broken, lots of thing are faster to do in command line than with a GUI.
There are Gnome ways to create your own menu or icons to do that, but you refuse the Gnome way
Same as above, wohoo great usability. Why don’t you remove the menu altogether since the user should not bother with it
Because, like I said before, this is where apps can be automatically added or removed by your installation method.
Besides hiding behind the O’Holy HIG does not make it any more usable, and nowhere in the HIG does it state “thou shall not be able to add or edit entries in thy menu, with a easy to use GUI”
I agree with you. I actually don’t know if it’s more usable. But I know one can’t please everyone. On one side, you hear people complaining that KDE offers too many options which are too complicated, and on the other side, people like you asks for more. I tell you, be it on Windows or Linux (Gnome or KDE), I NEVER saw ANY ordinary user edit its menu. Asking them to do that will give you a blank stare. They are barely able to put their most used apps on the taskbar (and I have ALWAYS saw them do that no matter what OS) to not have to access the menu. And when I say ordinary users, it’s actually pretty current with “power users”, which have their Windows desktops *littered* with icons, it’s completely unusable, but they seem to be fine with it. Given these behaviours I witnessed through years (and still witness now, more sanely in Gnome or KDE), I tell you I think the Gnome approach to menu edit is sufficient for the Gnome desktop. You still have alternatives, you could even use the KDE one if Smeg does not suits you, and I think this situation is perfect. You have simplicity and choice. It won’t bother me or any of my user if you add more in Gnome though, as they will never use this anyway (and I won’t either).
Yes, you have a nice and easy GUI and the application does all the mucking for you, so you as a users don’t have to. Thanks for making my point clearer
What you don’t understand is that in this case, you actually do more work than if you had edited the file directly. You still have to enter your language, and all the text for each field. But the GUI is useful for ordinary users, because understanding what to put in the icon field requires more knowledge than an ordinary user should have.
If all GNOME dev think like you (which I hope is not the case), I understand why GNOME is so full of flaws everywhere : you just believe users think like you, and if they don’t, it’s because they’re wrong.
you just believe users think like you, and if they don’t, it’s because they’re wrong
I wonder how you came to this conclusion, when all I say was that looking at users, what has been decided is enough, and there are ways to add more functionalities for those who wants, and finally, I don’t mind if more functionality is added.
I tend to see these discussions as trolls because I think most users are in one of these two categories :
– those who use a distro to obtain Gnome. These people never get the stock Gnome, so have no point in whining here, especially since the distros will most likely include a more complete menu editor, and you should complain to them.
– those who build the stock Gnome themselves. These people, like me, have the power and knowledge to at least add Smeg to their desktop, so I don’t understand their complaint.
The newbie is always in the first case, so what is the point of all this whining really ?
Smeg developers could complain to Gnome devs, but why other people complain too ?
So, for you, a menu editor is not needed and GNOME devs wasted time developping it ?
That’s your point. For me, when you start something, you can’t leave it half-done, and that is the situation right now.
Most users think developers are evil and arrogant when a
feature they want is not included in their favorite
applications. On this thread alone I have seen more
condescending slurs pitched at GNOME developers than
sentiments of appreciation.
The reality is that most users only see things from one
perspective — theirs. Most users believe they understand
their problem domain better than anyone in world, including
developers. So their argument goes that developers are
retarded for not providing option “A” and feature “B.”
The reality is that most users probably spend a total of
5 minutes, I’m being generous, thinking through the problem
domain, if at all they do that. Their argument goes, “option
“A” is in windows so why can’t GNOME have it.” “Feature “X”
has been in OS X for years, why can’t GNOME copy it.” “I
work with application “Y” this way in KDE, why can’t GNOME
let me do it that same way.”
Let me break it down. Those complaints are not solutions to
the problem domain. No, they are not! They are defined as
categorical whining. And if I see a bug report like that,
I’d be the first to close it and call the reporter’s father
a hamster for wasting my bloody time.
Developers follow and grok logic more than they appreciate
sentiments. “But OS X does it that way…” So? Who told you
the developer drank the OS X koolaid? Who told you the
developer has ever used OS X? And who told you the developer
agrees with the OS X way of doing things?
The truth is developers spend a lot more time — days,
weeks, even months — thinking about the problem domain and
analyzing every possible use case than most users have the
forbearance to withstand. In fact, the only time when a user
has the right to open their mouth is when testing the
application’s behavior.
Developers know no software is perfect. A concept
which is alien to most users. Users need to understand
every time feature “A” gets added into application “B”, it
means more testing, more paths to bugs, a longer maintenance
cycle and possibly more complexity. Again these are all
oblivious to most users.
Apple and Microsoft have access to UI designers,
professional testers, support call centers, software
consultants etc. Heck, they even have resources to outsource
boring tasks.
Free software developers must develop, test, design, support,
maintain websites, design logos, squash bugs, maintain
bugzilla and keep quiet when ungrateful beasts call them
unspeakable names. And most of them don’t even get paid for
this.
Let me summarize. 99% of the time, most users have not
explored their problem space as deeply as developers have.
So think twice before you open your lousy mouth to call
developers retards for not including option “X” which you
can’t leave without. There are probably very cogent reasons
for not including it. How many of you go to the doctor ill
telling her you know your body better than she does? That’s
what some of you seem to be alluding to.
Congratulations once again to the GNOME community, I look
forward to using 2.12 with all its flaws.
There’s no perfect software, just perfect compromises.
Did you try to change subject on purpose ?
When the application lacks essential functionality for lots of user it’s broken. Has noting to do with changing subjet, it is the subject. Passing the blame and claiming broken apps and chanting about some “standards” does not change fact.
The application menu is a centralized place for *automatically make a link to your installed applications*.
But the standard does not states only those, and the standard even describes how the user should be able to add to it by defining the layout in the users home dir. What you say is ridiculous!
so he can easily make a difference between original launcher and custom ones. So yes, it is more consistent and has better usability.
For the user an app is an app, regardless if he or someone else installed it. Your theories of usability gets stranger and stranger.
So you assume that in EVERY CASE, a good GUI is more efficient than editing a config file ?
Now I wonder if you are stupid on purpose, or perhaps have some kind of problem comprehend written English. I said simpler, so the rest of your points on this are both stupid and void.
On one side, you hear people complaining that KDE offers too many options which are too complicated,
Nonsens argument in this case, it’s about having a application actually do what it should have in the first place and not some lame halfbaked solution not able to solve the task. Making a application so simple it can’t preform the tasks it should, is not exactly usability.
What you don’t understand is that in this case, you actually do more work than if you had edited the file directly. You still have to enter your language, and all the text for each field. But the GUI is useful for ordinary users, because understanding what to put in the icon field requires more knowledge than an ordinary user should have.
My point exactly, you still keep on making my point clearer. The amount of work are a non issue anyway, no one sits all day editing desktop files. One of the key issues with usability is exactly what you describe here. Making the user able to preform a simple task, without requiring specialized background knowledge of how it’s achieved.
“In my opinion, the Gnome Desktop is the best X11 desktop system today from the user’s point of view when compared to the rest of the DE solutions.”
Random to say this without any comparisons or knowing how deeply you know the other “DE Solutions”.
To those saying GTK+ is slow, you probably haven’t tried Xfce. Xfce is lightning fast (much faster than both Gnome and KDE), and it’s fully based on GTK+.
Any slowness in Gnome comes not from GTK+, but from all the other libraries, metacity, pango, xlm based config files, and whatever else.
But alas, if you use a distro that is Gnome centric, or treats Gnome as a first class citizen, then Gnome is not slow. I’m currently typing this in FireFox, launched from Gnome 2.8, on a Debian Sarge installation. This installation has both Gnome 2.8 and KDE 3.3. This is on 300MHz, 256meg RAM machine, and both Gnome and KDE are very snappy, with Gnome actually being slightly faster. Now, I’ve also had Gnome installed with a Mandrake 10 installation, which defaults to KDE. In this case, KDE was faster, probably because Mandrake applied some optimizations to KDE.
So, GTK+ is very fast.
Gnome is fast too, if it’s implemented by a distro that makes it a priority.
“*If* KDE has the upper hand in *one* thing over Gnome, it is their great RAD tools and API documentation”
Nothing negative about that! KDE *might* be better than Gnome at a single thing! Not judgemental or dismissive at all
I can’t believe that over 100 posts in, there is still whining/arguing about a Gnome menu editor.
Give me a break!
First, you add and delete items on your menus right now, by opening the menu and right clicking on it and chosing the menu item.
Second, there are menu editors that can be downloaded.
Third, menu editing is not that important!
People who are whining about it seriously need to get a life. Seriously. If you are spending so much time b!tching about having a Gnome menu editor, you seriously need to evaluate how you spend your time. Move out of your parents basement. Get a job. Get a girlfriend. Do something.
BTW – the Gnome Devs are doing fine work. Gnome is not perfect, nor is KDE. Both are excellent DE’s, with their own strengths and weeknesses.