Submitted by “If you’re a GNOME user I expect you’re more than familiar with the panels that come as standard with your desktop; if you use openSUSE you’re probably also familiar with the slab menu that Novell have developed. There are, however, several other applications out there that can extend and beautify your Gnome panels.”
Me for once actually love the existing panels as they are and do not want any replacement. Its just one of the things that makes Gnome as perfect as it is. However, I do wish they would fix the window list applet though. Kind of annoying that the buttons keep resizing. Or at least they could create a hidden option in gconf or something to make a maximum size and minimum size of the buttons regardless of their title-length.
Edited 2007-07-25 14:46
This is already fixed.
http://bugzilla.gnome.org/show_bug.cgi?id=310809
Hidden option in gconf? You’re on crack.
This is already fixed.
It only took them four years. Not bad.
Yeah, great… isn’t it. You didn’t even have to lift a finger or pay a penny.
(I know, I know… there’s no excuse for it taking this long but some people just can’t stop whining. They are probably having too much fun doing it… Just be glad that such a long standing issue is finally fixed… It’s hard to stop whining, I know… but please, won’t somebody think of the children… *sigh*)
Also, it’s not fixed “properly” yet. Needs natural size stuff in GTK+ that hopefully will be done through GSOC. The dude working on it is making good progress.
Edited 2007-07-25 15:44
Gnome often has horrible turnaround on bugfixes.
See http://bugzilla.gnome.org/show_bug.cgi?id=145503
It took 3 years (with multiple patches submitted), was an incredibly easy fix, and without a doubt was the most annoying non-feature of gnome for people whom it affected.
As far as I can tell, it took so long to fix because one of the developers put a lot of time into making the software work in a way that no one wanted.
There is no excuse for it, I agree.
Every project has bugs, feature requests, etc. that hang around for years if that project has been around for years.
The length of time it takes to fix an issue is not a valid way to solely evaluate a project.
Honestly, I think that sitting on bugs that long is inexcusable. I’m not trying to bash gnome. I use it every day and I like it, but they seriously need to work on their bug triaging/responsiveness.
In this case, everything was done right according to the “open source development model”. Someone submitted a bug explaining why the behavior made xinerama with metacity unusable. Multiple patches were submitted by various people. Many users chimed in with “please apply the patch/fix the bug”, but not one person with gnome commit access actually applied those changes for *3* years.
google “metacity xinerama”. You’ll find that people have been patching their local version for years. It’s nice that they can do that I guess… open source and all. But still, it’s incredibly annoying.
I guess the worst part is that in the bug thread you can tell that anyone who actually has commit access and is discussing what the best course of action is *doesn’t actually use xinerama*. In other words, they don’t know what they’re talking about from a user’s perspective.
The point I was making is that every software project has bugs that they “sit on” for years. Quite frankly, it is a reasonable thing to happen.
Even in commercial software projects, even when possible fixes are available, bugs may sit open for years.
That is because those that are responsible for prioritising what gets fixed do not do so always in the way that they should.
As I said before, you could blame them for not proiritising the bug, but the length of time a bug has “sat” is not a valid point of evaluation for bugs solely as a performance indicator.
Unusable for his particular usecase. I’ve been using Metacity/Xinerama for many years now, but I’ve always had the physical screens right next to one another. I only keep a panel on one of the screens, so to have all applications open on that one would be severely non-optimal.
As far as I can tell, it took so long to fix because one of the developers put a lot of time into making the software work in a way that no one wanted.
Alas, this seems to happen quite a bit when you look around Bugzilla. In many cases, no one can even use the “We accept patches!” excuse because three different patches and fixes had been languishing around in Bugzilla for a couple of years.
This wouldn’t mean so much, apart from the fact that it seems to happen quite often sadly.
You just defined Gnome. And I use it as a default desktop on all my Linux boxes. Gnome’s developers often believe “keep it simple” = “you don’t need to do it that way” on usability issues. Try configuring a screen saver’s options, for example.
Again, I prefer Gnome. But the developers do need a kick in the pants every now and then, and these applet panels make it clear that there are users who feel Gnome has room for improvement.
Enough complaining. My personal favorite item was Gimmie for two reasons:
1. It allows you to drag-drop tag all documents like blog entries and search by those tags. Spotlight in OS X doesn’t touch this because it only searches text-based info boxes, leaving you responsible to remember tags. Mac was supposed to be about NOT typing.
2. It simplifies the address book down back to an folder based applet where the concept of people as resources comes first and specific implementations of communication second.
I’m cramming Gimmie on my laptop when I get home.
Scratch the comment about tagging. That’s Leaftag in action, and the developer didn’t explain it’s a separate product:
http://www.chipx86.com/wiki/Leaftag
All products have bugs.
All products have priorities for those bugs.
A bug not being fixed for four years *usually* means absolutely nothing except that it was not a high priority.
Now, with that said, you could argue that it should have been higher priority.
Nonetheless, the amount of time it takes to fix is an issue should not be the primary evaluation of how “good” a particular fix is.
The amount of resources available to fix issues is finite, which means that only so many can be fixed for each release.
All sane software development teams evaluate and fix bugs based on a variety of factors used for evaluation, and age is usually low on the list.
Edited 2007-07-25 18:53 UTC
In this case, it is a really bad delay… In four years, we had so many stupid things (spatial nautilus, mono epiphany) and this bug stays alive? As you say, it is a matter of priority, and I cannot understand GNOME’s priority!
I think that option to set minimum and maximum has been fixed for four years. Or at least it’s been there as long as I can remember. I’ve used Gnome since the 0.2 days. I think they may have lost it during the 1.x to 2.x transition, but been there for a very long time.
Or at least they could create a hidden option in gconf or something to make a maximum size and minimum size of the buttons regardless of their title-length.
The Panel Options already let you do that, set the minimun and the maximun width of the buttons, but Im not in my Ubuntu Box right now to show you a screenshot.
That site has a lot of banner ads, which visually makes the page difficult to navigate and read. I wonder how much money they make per page hit?
Offtopic!