40+ Suggestions for Better Desktop

http://bugzilla.gnome.org/show_bug.cgi?id=97609

Since everyone disagreeing with TopDown is stupid or ignorant, I'll reply to him as a contributor to Gtk and a binding author. Obviously, as TopDown is impervious to truth or actual knowledge, he will call me names. What can I say: I like TopDown attitude of spreading FUD and stupid assertions without any shred of evidence backing his claims.

It's built on the flawed concept of GObjects

I won't even begin to ask why: the reply would be a (mildy un-elaborated) "because", and since TopDown doesn't seem to understand or know the reasoning behind the choice of abstracting widgets signals, properties and inheritance using a C library, any counter-argument I could write would simply be useless, and bounce back on his thick skull.

it's got unfixable memory leaks when used with bindings

This is actually cute: writing a sentence which seems to be technical enough to give the impression that he knows something about it is a pure gem.

Sadly for TopDown: no, there aren't unfixable leaks when used with bindings. There are leaks - and valgrind is useful to track them and plug them, assuming valgrind is smart enough to plug into the new slab allocator used by GLib 2.10. If you are using valgrind and you want to remove all the spurious entries generated by gslice you can use environment variables to control the behaviour of the allocator.

In short it's practically designed to be slow and bloated.

And here's the money shot (and the non sequitur): since TopDown doesn't understand GObjects, and since he thinks he saw some traces while using valgrind on a python (?) application, then gtk was designed to be slow. And bloated, whatever that means.

And, again, how TopDown deals with this? By (poorly) ranting on a web forum (which the Gtk authors do not read), calling all the people correcting him "stupid", and generally trolling even in blogs. Bravo, my friend.

Debian - Even Hell Freezes Faster. -- seen on #debian-devel

I'm wondering how difficult would be, if feasible, to use the kernel VFS stack to implement it (i know that VFS isn't present in BSD and company anyway...)

I would love to have the ability to do a "cd file.zip" and it enter the file it self. This is an idea of the Reiserfs4, a file can be a folder and a folder can have contents, but I think this could be possible to handle by the kernel.

All the kernel would have to do is to make it possible to mount File systems into files. Then if you try to change dir into a file, the kernel would warn the GUI, via HAL(?), the gui would check if this is a compressed file and mount the apropriate FS, via FUSE(?) when this operation succeed the gui will prompt the kernel to retry the op, other wise it send an error to the user.

The gui, in this wild imaginative guess, could be a command line.

There should be a place for each idea, and a poll/comments for each idea to see how everyone likes it.

Excactly! But as you say it must be more official, both for the bandwidth, and to make people know about it. That's why I think it should be hosted at gnomelook.org. It may have only one poll, but it has also got a comment part...

I think that if hundred of thousands of users all could came up with usability ideas, some of them would be genius and innovative. Some that 100 developers had never thought of.
They don't have to be forced through, but then the devs can look and pick what they like.

But chatting over irc you lose the overview and ability to rate ideas.

Right key should go down and left: no. Right means right and only that. It doesn't mean "next".

Actually, it usually means exactly that under the circumstances. It's a wrapping view, as anyone can see when they resize the window - icons disappear from the left and appear on the right. So yes, I'd expect the arrow keys to be consistent with that, just as they would in a text editor.

It doesn't mean "next".
Is there any key that means "next"?

"Now playing" is not only notification for next song but also tooltip. When showing next song it is not necessary to show position but when you get it on-mouse-over tooltip it can be useful (you do not need to raise player window).

You are right some ideas are good some are not so good. Some are old and some are new. It's on comunity to say which they like and how they like it and on developers are listen to them and if they like it too they should try to do them best.

Right key should go down and left: no. Right means right and only that. It doesn't mean "next".
I agree, though I think the argument for having it automatically wrap is strong. It is similar to the behavior of many other applications. Making it an available option would be good, though I think the current behavior should remain the default.

If a user has problems with manual dexterity this won't work. They will hold the key down and it will fly away on them. Having it stop on the right or left is a good thing. I do agree for those of us this doen't affect, it would be a nice option.

This is in the same boat as a sound only for disk space...what about deaf users???

It's pretty common to give an option of giving BELL sounds visual cues (Like screen flashing) for people with bad hearing, I have a strong feeling that this would get the same treatment.