Hacker News new | comments | show | ask | jobs | submit login

Here's an annoying Gnome Panel bug that's been open for years:

https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/4... https://bugzilla.gnome.org/show_bug.cgi?id=341441

Changing the resolution of the display (ie., dock/undock laptop) causes the panel icons to shift around. The bug is marked fixed, but it isn't.

The issue is the way that the position of the icons is set by the user. By default, gnome sets the left-most icons to negative numbers as a position, and the right-most icons to some very high numbers. When a user clicks and drags their own applets to the panel, they are considered absolute positions and set their position in pixels.

The fix would involve an overhaul of the interface used to add icons to the panel, and it would not fix any existing panel configurations. It would also require at least some sort of an extra step of understanding for the user (Do you mean left justified, right justified, or absolutly positioned?) and some interesting Gnome-panel rendering hacks.

This is a lot of work for something that doesn't affect a lot of users, as most users do not customize their panels, and of those that do probably are not changing their resolution often. If someone who wanted to work on user interface hacking worked on other parts, such as improving file system access, preferences configuration, or even login screens, it would be more appreciated by more users.

This is exactly the kind of "reply" that seems to keep the open desktop crappy.

Sure, it takes work and testing to get a UI into a condition that seems, to the end-user, to just work

BUT that kind of work, each in the small end-cases that only come up ocassionally, is needed. Sure "that doesn't affect a lot of users...".. yeah it will continue to "not effect a lot of users"* as long your usability sucks and not one uses the thing...

An app or desktop or whatever needs to fully implement the features it claims to have. And it is often true that the last yard turns out to cost as much as the rest put together. Yes but the last yard is necessary. I can understand if it won't get done 'cause there's not enough time or money. But the attitude that it shouldn't get done 'cause "that doesn't affect a lot of users" makes my blood boil. Sorry, I'm sure people put lots of effort into this stuff but I just have to get this off my chest.

Look at it this way: Currently, there are a lot of problems with Ubuntu's user interface. The crappy way it deals with shortcuts when you click a menu. The ridiculous way that the calender flyout stays on top. The un-customizable log-in screen. The lack of vertical panel applets. The list goes on.

This complaint is similar to desktop icons not maintaining their position when you change desktop resolution. It requires far more work than changing the way the backend handles shortcut keys (to fix the menu bug), and doesn't improve most people's experience.

I'm not saying you're wrong! This is a legitimate problem! I'm simply saying that it's not a priority, similar to how it's not a priority for Apple to expose a user interface to customize the button layout on their windowing engine, or fix their dock to work properly in vertical mode. All projects have priorities, open source and closed source, and this bug doesn't seem very important to me.

I think he has a point insofar as Ubuntu's user interface has thousands of small usability issues like the one he mentioned; each of them a corner case that impacts a tiny subset of end users, and so each tends to get individually brushed aside because the fix would require a lot of hard work (polishing is, after all, about doing a lot of hard work), and wouldn't benefit that many people vs rewriting-the-audio-layer-yet-again or how-about-a-new-HAL-this-one-is-almost-mature or some other big/sexy project with mindshare.

The problem with that thinking is that all of those little corner cases, in aggregate, create a situation in which you are constantly encountering little unpolished, sharp edged bits of ungainly behavior, and it's never going to go away until people reject CADT-type behavior and realize that polishing enough corner-cases for small subsets benefits large majorities in aggregate.

Shuttleworth seems cognizant of this with his support for the paper-cuts project, but there's too little of this polishing going on upstream for a 100-odd little fixes per-release effort to really tip the balance too far towards improvement.

I also don't want to say that any of this is easy.

Open source has a different problem from closed source in the sense that the "sausage making" is visible from the outside.

I don't think that processes or design principles of closed source companies and products is applicable. Is important to prioritize and manage what's happening ... It's just that it's important to do that in a way that makes lets the random person walking-in feel like they've begun to participate rather than giving an answer like "who let you in". (essentially should be the opposite of Linus managing the Kernel).

Perhaps a "friendly bug reception area" would be a worthwhile project. Launchpad may be very functional in ways but I'd say it's very, very broken as far feeling you're participation valued. A random bug thread is "comment-1, comment-2... little-icon-saying-this-is-not-a-bug-with-little-explanation". Just a longer boiler-plate explanation for changes like could be more soothing.

I will even admit that I have personally never experienced this problem but your original answer STILL ticked me off and I think there's a reason other than general Internet annoyance.

What I have experienced is the "Internet Interface" of ....

"Whatever the problem is, the first answer is 'it's not a priority'"

THAT needs to be tweaked. I understand prioritizing things. But we really, really, really need a way to relate to those frustrated by and reporting X that doesn't involve "answer 1: we don't care about X" because that has as it's implicit message "screw you".

Edit: Also, the original problem is something really looks like a bug to the end-user whatever is may look like the programmer. So fixing it should be "bug priority" whereas a number of the thing you mention are clearly features, look like features to the end-user and so should have "feature priority". Just consider...

> This is a lot of work for something that doesn't affect a lot of users, as most users do not customize their panels, and of those that do probably are not changing their resolution often.

I'd say the duplicate bug count, angry comment count, subscriber count would disagree with you.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact