Lobster wrote:I do not read the manual when using a word processor.
I know how to use one.
You lost some important details in this statement; *now* you know how to use *one specific brand* of word processor - and *maybe* can feel your way through an imperfect imitation of same. You weren't born with the knowledge; you were forced to acquire it - maybe indirectly, just by everyone around you using that specific product, but still forced.
And now you want all other word processors ever to exist to imitate that one specific brand which you know. Understandable - but not rational.
Ease of use is not an afterthought. It is integral to how people use a program. If it is unclear or obscure or difficult, who is responsible for this?
"Ease of use" is a marketing fantasy. I lost count of weird problems with "The One True Word Processor" that made users run to me for help - and still, people forget about all that the next day, but are ready and willing to hate OOo for some button not being in the "proper" place.
People use whatever software they cannot avoid using, and rationalize having to use it into "liking" it - and likely rationalize their unwillingness to learn anything else into reasons to dislike it. Take any GIMP-vs-Photoshop flamewar for a ready example.
This is why I focus on features, binary size and efficiency - when for some niche there is no other realistic choice except mtPaint, then users in that niche learn to like mtPaint.
I am offering you the possibility of clearer icons because I believe they are obscure.
Life taught me that the time to take an offer of something seriously is when the offered stuff is on my harddrive - and not before. Saved me a lot of disappointment.
Programs would work perfectly if only they remained unused by people .. . ..
Exactly the reason why the majority of FOSS projects are "by programmers for programmers".
Software ergonomics are important. If you feel they are not, then I am at a loss to understand how a program where new features are not accessed is developing?
Don't tell me of "software ergonomics" when people not only use Photoshop and GIMP, but learn to like them.
The kind of ergonomics I care about, is one supported by use cases - if some real-world task is awkward to do using the interface, then the interface needs improvement, but if the only problem with the interface is that it is unfamiliar, then so be it.
Quite a few things are
*really* awkward and limited in a "standard" (aka Photoshop-clone) interface; and in these areas, mtPaint goes its own way: channels, modes, "gradient placement".
And other things might be good to have in principle, but are either uninteresting, or too much work for too little gain. Skinnable interface is one example.
And remember that any new feature in mtPaint has at least one user: either myself, or Mark Tyler.
So if something is done a certain way, it is because one of us considered it best (or, at least, good enough) for his own use. And if the way it is done turns out to be wrong for some other use, to get it fixed I need to at least know what the problem is.
Apart from reading the manual, what feedback or help can we suggest or offer?
Like I said - use cases. Things which users want to do with mtPaint, and for which mtPaint is currently deficient, or awkward to use. I use mtPaint in certain ways for certain tasks, but (naturally) I do not even think of some things which someone else would want from a graphics editor.