OSNews

The change seems simple, but the last comment reveals a bigger issue. In order to implement your good change, GNOME would need to create a new theme element. You can't just hard-code the background as grey since if you use a theme with grey letters, nothing will be readable.

That being said, there is another approach -- reuse existing themed elements. For instance, turn each section into into a tab:

-------------
Section 1 |
-----------------------------------------------
Items in section 1

-------------
Section 2 |
-----------------------------------------------
Items in section 2

At the moment, that page looks like it's just a huge custom control that draws bold text for the sections and then draws the section links and you can click on.

Drawing the darkened banner on the back is not that hard, even if you are worried about the usability repercussions. There must be the GTK equivalent to the Win32 function GetSysColor which allows you to retrieve the various colors associated with the current theme. One possibility in this scenario is to make the background of the banner use the color of controls (like buttons) and have the text colored the same as the theme's text color.

That way, if you can read the text on a pushbutton on a particular theme, you should have no issues with the banner. If you can't read the text, you're probably going to have issues reading text on controls anyway so go shoot your theme designer.

That makes no sense what-so-ever.

I don't see why it needs to be a theme colour, there is a very simple solution for it, just have a semi-transparent gray overlay when the background is light and semi-transparent white overlay when the background is dark.

This is a simple solution that will work with any theme, probably not 5 minutes but I doubt it would be an hours work.

Stop making excuses, the developer is obviously lazy

Five hours seems like a tiny investment for something that you have apparently been harassing the gnome developers about for over a year :-)

Does that 5 hours for you include all the requisite QA that really needs to be done to verify that it doesn't screw up more than it supposedly fixes?

If you have serious experience in development with complex projects, you'd be more aware that those 5 minute changes often have much greater repercussions than you'd think, and you need to verify that you haven't forgotten something before you submit it into the great wide open. Something that can be added in 5 minutes without proper consideration and testing can have a multiplier effect in terms of all the things that no longer work as intended or expected, and this is multiplied by the number of users times the number of things it breaks for the users. If the QA is thorough, that by itself is not a 5 minute thing, and may take some unpredictable amount of time, due to ensuring that all test cases (this appears to be a highly visual thing that needs to be checked manually, making it that much more of a hassle) pass that are known, and taking reasonable efforts to putting negative tests into place: purposely trying to break things to see if they will break.

Stick to your editorials, and don't go presuming you can instruct developers on how to do their work, or that they should work on your pet project, regardless of how valuable you think it is. At best, this is merely an "enhancement" which is in the eye of the beholder (or in the case of FOSS, in the eye of the beerholder) and may cause more problems than it solves for others. Just for example: how deeply have you analyzed your suggestions for those with color perception issues? There's lots of standard editor themes that for me, even though I have no color perception problems from a medically verifiable standpoint, are horribly intolerable and useless to me, due to sensitivities, but then again, they may work fine for those that are some variation of colorblind. As long as others don't force me to use those themes, ok, I can deal with that. Have you verified that your suggestion is readable to everyone that may use it on the various rendering devices (LCD, plasma, CRT, etc.) and aren't just setup well for a single device? I'm hoping you can see that there may be far more involved than you think when it comes to making a change that affects a lot of people like this.

Exactly, nothing ever takes 5 minutes to fix.

I used to play world of warcraft in my free time, and it was painful reading the forums. There were hundreds if not thousands of clueless kids who presumed to tell the developers that fixing stuff like network lag(!! lol!) was a 5 minute job and that they should get right on it.

I had a good laugh, then a good cry and then I left that place for good.

Wait, they do QA???

The screenshot you post isn't even of something that is part of Gnome...

Try posting the "bug" to the right place perhaps? Also, why are you using OSNews to publicize something you think is important, but which no one else really cares about?

The only good thing about SLAB is that you can remove it from the panel.

Why so much venom in these comments?

Technological progress happens because of one thing: INNOVATION. If the linux community puts up such high walls over such a simple feature request, what does that say about it's willingess to adapt and innovate?

So sad.

People get so fixated on the particular technology -- in this case, some aspect of GNOME -- that they have to make the problems fit the technology and not the other way around. How crazy is that?

What I'm trying to say is that instead of asking "How can we make GNOME better?", we should be asking "How can we make DE's (desktop environments) that are more easily modified by the user to fit their custom requirements?" Instead of searching for the elusive, best possible 'one size fits all' result, we need to keep it simple and allow the user more freedom of choice and that includes the choice to more easily create their own solutions.

Linux is free, sure, but the barriers for customization are intimidating to most. When the proposed change can be implemented as easily as writing a Firefox add-on, an xml file, or a cascading stylesheet, maybe then we'll have the creative freedom that is sorely needed.

Edited 2008-07-08 03:58 UTC