[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gets rid of length in the docs. (issue 4965053)
From: |
Mike Solomon |
Subject: |
Re: Gets rid of length in the docs. (issue 4965053) |
Date: |
Mon, 29 Aug 2011 10:11:19 +0200 |
On Aug 29, 2011, at 9:53 AM, Graham Percival wrote:
> On Mon, Aug 29, 2011 at 07:45:04AM +0000, address@hidden wrote:
>> I can't say I like this change: it makes a complex user
>> interface more complex. Shouldn't we be moving in the
>> opposite direction?
>
I disagree.
There used to be length, stem-begin, stem-end, and Y-extent properties for stem
- all of which were combinations of each other in some form. In theory,
stem-begin + length * dir = stem-end. (cons stem-begin . stem-end) = Y'extent
for up-pointing stems. etc. This also messed up pure heights. For example:
let's say that the user modified the stem-begin in the old master. This would
not have been taken into account for pure heights in certain situations.
Furthermore, a modification of stem-end with a modification of length could
result in one trumping the other in certain circumstances. In general, when
there are 4 properties (length, stem-begin, stem-end, and Y-extent) that
represent one, and when three of these properties lead to bad pure heights, I
think it is important to slim it down to one property (Y-extent). To me, this
seems less complex. And, if the user wants to set length with the beginning at
the note-head, stem::length is the appropriate function that will preserve pure
heights (with my pure-closure patch, which I believe will be going on a
countdown soon).
> On general principle I agree, but I believe that this patch simply
> brings the docs in line with actual git master.
Yes
> I assume that the
> examples about stem length currently just do nothing.
True
> As such, I
> think we should go ahead with it.
>
Agreed.
> 32570e8ac85561afc1f59712301ee80c0d69d2b3
> The one-line summary doesn't mention anything about syntax
> changes, but the detailed commit message makes it clear.
>
Yes.
> Moral of the story? pay more attention to patch countdowns, I
> guess.
Agreed.
> I wouldn't be adverse to asking developers to clearly
> state a syntax change in the 50-character summary (although this
> gets tricky; maybe simply adding "(syntax)" would be ok?)... but
> at the end of the day, the patch went through the countdown.
>
This I'll do from here on out.
Cheers,
MS
- Gets rid of length in the docs. (issue 4965053), mtsolo, 2011/08/28
- Re: Gets rid of length in the docs. (issue 4965053), percival . music . ca, 2011/08/28
- Re: Gets rid of length in the docs. (issue 4965053), mtsolo, 2011/08/28
- Re: Gets rid of length in the docs. (issue 4965053), mtsolo, 2011/08/28
- Re: Gets rid of length in the docs. (issue 4965053), mtsolo, 2011/08/28
- Re: Gets rid of length in the docs. (issue 4965053), tdanielsmusic, 2011/08/29
- Re: Gets rid of length in the docs. (issue 4965053), Graham Percival, 2011/08/29
- Re: Gets rid of length in the docs. (issue 4965053),
Mike Solomon <=
- Re: Gets rid of length in the docs. (issue 4965053), Trevor Daniels, 2011/08/30
- Re: Gets rid of length in the docs. (issue 4965053), Mike Solomon, 2011/08/30
- Re: Gets rid of length in the docs. (issue 4965053), Graham Percival, 2011/08/30
- Re: Gets rid of length in the docs. (issue 4965053), Mike Solomon, 2011/08/30
- Re: Gets rid of length in the docs. (issue 4965053), Graham Percival, 2011/08/30
- Re: Gets rid of length in the docs. (issue 4965053), Dmytro O. Redchuk, 2011/08/30
- Re: Gets rid of length in the docs. (issue 4965053), Dmytro O. Redchuk, 2011/08/30
- Re: Gets rid of length in the docs. (issue 4965053), Mike Solomon, 2011/08/30
- Re: Gets rid of length in the docs. (issue 4965053), Dmytro O. Redchuk, 2011/08/30
- Re: Gets rid of length in the docs. (issue 4965053), Mike Solomon, 2011/08/30