| |||||||||||||
GNOME and the way forwardGNOME and the way forwardPosted Aug 18, 2005 3:03 UTC (Thu) by hp (subscriber, #5220)Parent article: GNOME and the way forward
Lots of times people don't appreciate the efforts that were made. For example, this 100-post LWN flamewar was about Emacs-style keybindings...
The GTK+ team went to a significant extra effort to offer an Emacs key theme when GTK+ 2.0 came out, it's been there ever since, and the GNOME usability team even documented it in the Human Interface Guidelines:
In fact, how to choose the Emacs key theme is the first item in the GTK+ 2.0 release notes in 2002:
GNOME does have a lot of accomodations and features designed for people used to UNIX, and more of these features have been added over time.
That said, the goal is a "mainstream" rather than "UNIX" desktop and that goal has always been explicit. So _when_ there's a tradeoff or conflict the needs of office workers will win out over those of a 20-year UNIX sysadmin. Not a secret.
(Log in to post comments)
GNOME and the way forward Posted Aug 18, 2005 4:04 UTC (Thu) by piman (subscriber, #8957) [Link] Havoc,
Thanks. I've been using the GTK 2.0 Emacs bindings since they were the GTK 1.3 Emacs keybindings. I seriously didn't understand the flamewar that was happening in the other thread. I've also had no serious problems with clipboards; X primary selections have been that ephemeral for as long as I've been using Unix.
One of the biggest problems in free software is that there's no an easy way to file an "it-works-great report".
GNOME and the way forward Posted Aug 18, 2005 4:55 UTC (Thu) by iabervon (subscriber, #722) [Link] The problem with the Gtk emacs keybindings is that Gtk implements them differently from how emacs does. Consider, for example, Ctrl-K.I use it as the sole way I copy or move text in Emacs, by hitting it repeatedly until the area I want to copy has been cut and then hitting Ctrl-Y if I wanted to keep it, moving to the destination, and hitting Ctrl-Y. In Gtk, however, Ctrl-K has no effect, unless I've told it that I want emacs keybindings, in which case it deletes all of the text I want to copy. Alternatively, I could try using Ctrl-W, but that tends to close the window instead (definitely if the text entry doesn't have focus). After I've forgotten that I'm using Gtk and done something wrong, I type Ctrl-_ to undo it, but this has no effect. I don't know if a set of keybindings could be designed to be more hostile to emacs users. (That page tells you not to use the standard application shortcut keys for anything else, and then uses one of them in the emacs keybinds for something else; it also tells applications not to use symbols that require shift in shortcuts, and then doesn't bother to implement one of the emacs shortcuts that is therefore free.) In order to save myself, I avoid using any shortcuts or pressing Ctrl or Alt while a Gtk application has focus, and never restructure my text.
I will note that OS X's emacs keybindings actually get Ctrl-K right, so it is possible. (Pressing Ctrl-K cuts to the end of the line, unless the cursor is at the end of the line, in which case it cuts the line break, and pressing it again without intervening keypresses appends the removed text to the clipboard rather than replacing it.)
GNOME and the way forward Posted Aug 18, 2005 12:28 UTC (Thu) by hp (subscriber, #5220) [Link] Maybe the bindings can be improved, nobody is against it in principle afaik. Someone has to do the work though.
Obviously we aren't going to fully implement Emacs, so they will always be sort of limited vs. Emacs itself.
GNOME and the way forward Posted Aug 18, 2005 14:10 UTC (Thu) by ajross (subscriber, #4563) [Link] I think the poster was a little confused. The ^K behavior he describes for OS/X is identical to the one I see in FC4's 2.10 gedit. The other complaints are about the lack of GNU Emacs's selection and copy behavior, which have never been traditionally part of "emacs keybindings" (e.g. the Motif widgets didn't support them either), which actually predate the GNU program by quite a bit.The collision between the window keybindings and the emacs ones, though, is a good point. I have the emacs cursor movement keys in my synapses and they (^P ^N, ^F, ^B) tend to have very surprising effects when they get sent to non-emacs windows. Maybe someone could hack at the event precedence so a text field with focus can intercept them selectively, as part of the theme?
GNOME and the way forward Posted Aug 18, 2005 16:47 UTC (Thu) by dskoll (subscriber, #1630) [Link] So _when_ there's a tradeoff or conflict the needs of office workers will win out over those of a 20-year UNIX sysadmin. Why does such a tradeoff or conflict exist? Could I have an example? Here where I work, the developers use Linux, and the salespeople use Linux, and I don't think either group feels particularly restrained by the other. Linux desktops work pretty well for both groups. Assuming such a tradeoff is necessary, any UNIX-based desktop system that cannot allow a user to choose which way to resolve such a tradeoff, but instead hard-codes it, is badly designed.
GNOME and the way forward Posted Aug 18, 2005 17:09 UTC (Thu) by hp (subscriber, #5220) [Link] The most obvious form of the tradeoff is that you have two very different lists of requests and priorities from the different users, and you have to allocate developer time between working on one list vs. the other. No way around that. The only world without tradeoffs is one with infinite resources.
Another easy-to-understand tradeoff is that lots of people here seem to be requesting the UNIX behavior _by default_ and all defaults are a tradeoff vs. the other possible defaults.
Some other tradeoffs are mentioned in http://ometer.com/free-software-ui.html for example
It's tough to really have a feel for why there are tradeoffs until you've worked on the software for a while and seen how a design is done and how the maintenance issues unfold over time.
But while we can nitpick I don't see how some of these tradeoffs are arguable. There's obviously only finite developer time, and there's obviously only one set of default settings.
GNOME and the way forward Posted Aug 18, 2005 17:32 UTC (Thu) by dskoll (subscriber, #1630) [Link] The only world without tradeoffs is one with infinite resources. Agreed. So when a developer does all the work for you, and presents you with working code that does something useful for UNIX geeks, why not include it? Apparently, the Evo. developers just ignore such submissions unless it fits into their view of the world. But while we can nitpick I don't see how some of these tradeoffs are arguable. They are absolutely arguable. The kinds of things I'm looking for, and other UNIX geeks are looking for, are things like standard X cut/paste behaviour, ubiqitous support for external editors and adherence to long-established UNIX software traditions. These are all easy to implement (in fact, some of them take effort not to implement), and have been implemented quite successfully by KDE. They also don't affect newbies who don't want or care about them -- just don't use an external editor if you don't want to, for example. Use ^C/^V if you want for cut-and-paste. If Gnome wasn't planned right from the start to permit these kinds of things easily, then as I said before, it's badly designed.
GNOME and the way forward Posted Aug 19, 2005 1:49 UTC (Fri) by hp (subscriber, #5220) [Link] An initial patch is very much not "all the work for you." Any practicing software developer can tell you that at least 80% of the work is maintenance, not the patch. I don't know a thing about Evo external composer and haven't read the bug, but I can easily imagine the poor maintainer having to work around some complicated external editor mess when implementing features, and having to endure endless bug reports about how external Emacs doesn't quite work in various ways, or vim changed how it works and Evo needs adapting, and so forth.It could easily be a major time sink.
As it happens I've already written this argument down too: http://ometer.com/features.html
On the "it would be easy if it weren't badly designed" comment, I don't know where you get Magic Programming Silver Bullet(tm) with no tradeoffs or costs, but if you have it by all means come design things for us!
In the end I think most people who flame passionately about a small feature miss the simple point that there are hundreds of people flaming passionately about hundreds of small features. The maintainer is seeing the hundreds, and you are seeing the one.
Maintainers need some way to prioritize that.
GNOME and the way forward Posted Aug 19, 2005 2:00 UTC (Fri) by dskoll (subscriber, #1630) [Link] > An initial patch is very much not "all the work for you.
The Gnome-vim guy is maintaining his patch, and even maintaining a patched version of Evo on his download site. If he can do it, so can the Evo developers, so that they can cease to be the *ONE AND ONLY* UNIX mail client that lacks external editor support.
> I can easily imagine the poor maintainer having to work around some complicated external editor mess
Software that makes invoking an external editor a "mess" is badly designed.
> As it happens I've already written this argument down too: http://ometer.com/features.html
But IMO, the GNOME developers ignore an important point you make in that article:
"In the presence of good rationale, maintainers should be willing to change their mind often."
OK. Let me follow your article about just this one feature (external editor support where possible.) You want a rationale that:
"Does not apply to all possible features."
OK.
"Contains facts or empirical data rather than speculation."
Every other significant UNIX MUA supports this feature. 80% of the developers I have ever worked with have used this feature.
"Demonstrates that you've done your homework on alternative solutions to the same problem."
The alternative would be to rewrite users' favourite editors within GNOME.
"Demonstrates that you know what the root problem actually is; what motivates the feature? How else could it be approached?"
The root problem is that many people are most efficient editing text in their favourite text editor.
"Demonstrates that you're thinking of all users in the big picture, instead of just yourself and people like you."
All users who like their favourite text editor will benefit. Those who don't care won't be hurt.
"Improves things for a large percentage (50%?) of users, or makes the impossible possible for a smaller percentage (5%?). "Easy things easy, hard things possible.""
I believe this feature request covers the 5%.
"Shows that the feature is genuinely important enough to be worth maintaining some extra code."
One developer is already maintaining the extra code in his own free time.
Happy?
> In the end I think most people who flame passionately about a small feature [...]
I'm not just flaming about one small feature (although it is highly irritating). It's the *combination* of small misfeatures, bad design decisions, and (mostly) incredibly haughty attitude of the developers that has soured me on GNOME. I have to agree with some of the other posters here; the 1.4->2.0 transition really marked a significant decline in GNOME's usability and quality.
GNOME and the way forward Posted Aug 20, 2005 0:52 UTC (Sat) by sandmann (subscriber, #473) [Link] Here is a fact you people might want to consider: Nobody actually *likes* the unix mail programs with their external editors. Their combined market share is perhaps 2%.
If you try to say that those 98% of all people just need to get used to the unix way and put up with meaningless preferences like "path to external editor", then you need to reconsider who the arrogant twit is ...
GNOME and the way forward Posted Aug 20, 2005 3:24 UTC (Sat) by dskoll (subscriber, #1630) [Link] Here is a fact you people might want to consider: Nobody actually *likes* the unix mail programs with their external editors. Their combined market share is perhaps 2%. If you are talking about market share of all e-mail programs, you're probably right. If you are talking about market share of all e-mail programs that run on UNIX, you are completely wrong. Evolution is the only UNIX-based e-mail program I can think of that does not support an external editor, and I'd be amazed if it has more than 25% market share among UNIX e-mail programs.
GNOME and the way forward Posted Aug 25, 2005 9:16 UTC (Thu) by k8to (subscriber, #15413) [Link] I've been using email for decades now, and have been through a huge range of email programs: mailx, eudora, pine, elm, a variety of wonky BBS-based acess methods, whatever the mail was on our VMS systems, pegasus mail, yahoo mail, gmail, and I've pretty much always come back to elm, and more recently mutt. It's just better at getting the job done. Despite significant experience with all the others, I really quite like it.
And you know I'm editing this web form in gvim too. A feature the mozilla people have had requested since it started without ever being satisfied.
Thanks for calling me a nobody.
GNOME and the way forward Posted Aug 25, 2005 13:03 UTC (Thu) by zdzichu (subscriber, #17118) [Link] There is not need to put this preference in Evolution.There is already Prefered Application submenu in preferences. Default editor could be put there.
HP's "Good UI" article. Posted Aug 18, 2005 17:38 UTC (Thu) by dskoll (subscriber, #1630) [Link] Regarding http://ometer.com/free-software-ui.html
There's no such thing as a universally "good" UI. That's like saying yellow is a "good" colour. The only definition of a "good" UI that counts is: A good UI lets the user get things done quickly, easily, accurately and with a minimum of fuss. By that definition, a good UI for me is the Nirvana of a Bash prompt, whereas for others, a good UI might be Windows 3.1 (because that's what they're used to, dammit!) So trying to design an objectively good UI is doomed to failure. The best we can do is design a UI that's "OK" by default, but that lets individual users tune it until it becomes their personal "good" UI. The way GNOME is going, we'll all be using an OK-by-default UI without the ability to make it a good UI.
|
|||||||||||||