On 06/08/11 08:47, David Kastrup wrote: > The compromises between the wishes of people and the technical feasible > things and those you want to do are a moving target. And the > responsibility for making technical and logical impossibilities > disappear, to match the program better to expectations and requirements, > is only something the experienced programmer can do. Sometimes the > results please the user more than the programmer. It is hard to > generalize this into policies, since a policy would not change its mind > if enough people bother it.
And sometimes, the user needs results that the programmer hates. At the moment, I've got a piece of music I need to clean up because it looks awful. And it looks awful because I've forced it into a straitjacket it doesn't fit properly. BUT. The whole philosophy of lilypond is that beautiful music is easily playable music. *Mostly* that's true. But as a bandsman, I place a *very* high penalty on page breaks. I wish I could force lily to force music on to one, or at most two, pages. But that goes completely against the grain of what most lily people want. Unfortunately, to me, music with page turns can far too easily be unplayable. It's all very well saying "it's easier to read" but that's no consolation when it's doing a fifty yard sprint down the field away from me! :-) I know asking users to categorise importance to them is hard - yes they'll often say any bug is a serious bug - but to me for example printing one last stave on page two instead of cramming it onto page one is a massive failing of lily as a "master engraver". No disrespect to the programmers (heck, I'm trying to become a contributor myself, in part because I want to correct the failings I see), but by default lily does a very poor job of minimising wasted space by default on small scores. To me that's a very serious failing, but most programmers don't see that. Maybe we should have some scoring system whereby things are graded both on importance to user, and ease of fixing, along with program integrity (ie how serious a programmer would rate it - segfault, buggy code, etc). My formatting issues would probably rate about 1 on ease of fix and program integrity, but the higher the average score the more critical the feature because fixing it would have a far bigger impact across the board. Cheers, Wol _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
