| |||||||||||||
GNOME and the way forwardGNOME and the way forwardPosted Aug 19, 2005 1:49 UTC (Fri) by hp (subscriber, #5220)In reply to: GNOME and the way forward by dskoll Parent article: GNOME and the way forward
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.
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.
(Log in to post comments)
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.
|
|||||||||||||