[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 8: issue priorities

From: Wols Lists
Subject: Re: GOP-PROP 8: issue priorities
Date: Sat, 06 Aug 2011 14:33:46 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110713 Lightning/1.0b3pre Thunderbird/3.1.10

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]