I have a headache after the first file of 30, so this is just this one
file and does not imply that the others are fine.
https://codereview.appspot.com/7185044/diff/164001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (left):
Hey all,
Following up to my comment on the tracker, I'd like to not push this
until everyone has had a chance to think through David's e-mails about
2.18. I anticipate this needing 2-3 months of user testing to catch and
fix any bugs. Given that this is my first big patch since August, it'll
On 2013/02/24 16:20:53, mike7 wrote:
On 24 févr. 2013, at 17:18, David Kastrup mailto:d...@gnu.org wrote:
m...@mikesolomon.org mailto:m...@mikesolomon.org writes:
On 24 févr. 2013, at 16:37, mailto:d...@gnu.org wrote:
On 2013/02/24 13:27:39, mike7 wrote:
On 24 févr. 2013, at 12:40,
On 25 févr. 2013, at 16:29, d...@gnu.org wrote:
On 2013/02/24 16:20:53, mike7 wrote:
On 24 févr. 2013, at 17:18, David Kastrup mailto:d...@gnu.org wrote:
m...@mikesolomon.org mailto:m...@mikesolomon.org writes:
On 24 févr. 2013, at 16:37, mailto:d...@gnu.org wrote:
On 2013/02/24
On 25 févr. 2013, at 23:34, m...@mikesolomon.org wrote:
On 25 févr. 2013, at 16:29, d...@gnu.org wrote:
On 2013/02/24 16:20:53, mike7 wrote:
On 24 févr. 2013, at 17:18, David Kastrup mailto:d...@gnu.org wrote:
m...@mikesolomon.org mailto:m...@mikesolomon.org writes:
On 24 févr.
This still needs some cleanup, at least to remove the now-redundant
\tupletOutsideStaffPriority
The goal was to have outside-staff grobs figure their own Y-offset,
including the offset required for the outside-staff grobs to avoid each
other. The group of all objects on a line
Stupid question: could you not just check whether outside-staff-priority
has been set, and if it has, pass the buck to the right kind of callback
automatically? That way, the user does not need to meddle with
callbacks himself.
https://codereview.appspot.com/7185044/
On 24 févr. 2013, at 12:40, d...@gnu.org wrote:
Stupid question: could you not just check whether outside-staff-priority
has been set, and if it has, pass the buck to the right kind of callback
automatically? That way, the user does not need to meddle with
callbacks himself.
On 2013/02/24 13:27:39, mike7 wrote:
On 24 févr. 2013, at 12:40, mailto:d...@gnu.org wrote:
Stupid question: could you not just check whether
outside-staff-priority has been set, and if it has, pass the buck
to the right kind of callback automatically? That way, the user
does not need to
On 24 févr. 2013, at 16:37, d...@gnu.org wrote:
On 2013/02/24 13:27:39, mike7 wrote:
On 24 févr. 2013, at 12:40, mailto:d...@gnu.org wrote:
Stupid question: could you not just check whether
outside-staff-priority has been set, and if it has, pass the buck
to the right kind of callback
m...@mikesolomon.org m...@mikesolomon.org writes:
On 24 févr. 2013, at 16:37, d...@gnu.org wrote:
On 2013/02/24 13:27:39, mike7 wrote:
On 24 févr. 2013, at 12:40, mailto:d...@gnu.org wrote:
Stupid question: could you not just check whether
outside-staff-priority has been set, and if it
On 24 févr. 2013, at 17:18, David Kastrup d...@gnu.org wrote:
m...@mikesolomon.org m...@mikesolomon.org writes:
On 24 févr. 2013, at 16:37, d...@gnu.org wrote:
On 2013/02/24 13:27:39, mike7 wrote:
On 24 févr. 2013, at 12:40, mailto:d...@gnu.org wrote:
Stupid question: could you not
On 24 févr. 2013, at 11:45, k-ohara5...@oco.net wrote:
This still needs some cleanup, at least to remove the now-redundant
\tupletOutsideStaffPriority
It's not redundant just cuz if it's not set, LilyPond will now issue a warning.
If you want the regtest to have a warning, we can convert
https://codereview.appspot.com/7185044/diff/45018/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/7185044/diff/45018/Documentation/changes.tely#newcode68
Documentation/changes.tely:68:
https://codereview.appspot.com/7185044/diff/45018/input/regression/tuplet-bracket-outside-staff-priority.ly
File input/regression/tuplet-bracket-outside-staff-priority.ly (right):
https://codereview.appspot.com/7185044/diff/45018/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/7185044/diff/45018/Documentation/changes.tely#newcode73
Documentation/changes.tely:73: @code{Slur}, for example, are all grobs
are traditionally
On 18 févr. 2013, at 20:07, d...@gnu.org wrote:
A music function could be done in the form of:
\addOutsideStaffPriorityToGrob #'TupletBracket #100
that rolls the two overrides into one. This is a UI issue about
which I have not thought yet but that absolutely deserves attention.
On 18 févr. 2013, at 20:07, d...@gnu.org wrote:
On 2013/02/15 06:37:20, mike7 wrote:
https://codereview.appspot.com/7185044/diff/32003/input/regression/tuplet-number-outside-staff-positioning.ly#newcode15
input/regression/tuplet-number-outside-staff-positioning.ly:15:
\override
From: m...@mikesolomon.org
Sent: Monday, February 18, 2013 8:32 PM
On 18 févr. 2013, at 20:07, d...@gnu.org wrote:
You can't just throw functionality overboard when you are improving
things and tell people they have to revert to the old code if they
care about that functionality. After
On 19 févr. 2013, at 16:11, Trevor Daniels t.dani...@treda.co.uk wrote:
From: m...@mikesolomon.org
Sent: Monday, February 18, 2013 8:32 PM
On 18 févr. 2013, at 20:07, d...@gnu.org wrote:
You can't just throw functionality overboard when you are improving
things and tell people they
From: m...@mikesolomon.org
Sent: Tuesday, February 19, 2013 2:22 PM
On 19 févr. 2013, at 16:11, Trevor Daniels t.dani...@treda.co.uk wrote:
From: m...@mikesolomon.org
Sent: Monday, February 18, 2013 8:32 PM
On 18 févr. 2013, at 20:07, d...@gnu.org wrote:
You can't just throw
On 2013/02/19 14:57:48, mike7 wrote:
The current documentation on outside-staff grobs reads:
Intuitively, there are some objects in musical notation that belong
to the staff and there are other objects that should be placed
outside the staff. Objects belonging outside the staff include
things
On 19 févr. 2013, at 19:27, d...@gnu.org wrote:
You don't document what it takes to _keep_ adhering to
outside-staff-priority. This was previously something that worked
without extra measures. What does it take now?
I have put things in the change-log regarding this. Let me know if this
On 2013/02/15 06:37:20, mike7 wrote:
https://codereview.appspot.com/7185044/diff/32003/input/regression/tuplet-number-outside-staff-positioning.ly#newcode15
input/regression/tuplet-number-outside-staff-positioning.ly:15:
\override TupletBracket.Y-offset =
The reorganization looks reasonable.
{ g4\ g'_pico g' g\! }
Assuming for simplicity that this is set in one line, one
VerticalAxisGroup contains all the graphical objects as 'elements'. At
some point the Y-offset of TextScript pico is evaluated, calling
aligned_side() and then
I've not really reviewed everything here, just highlights. Regarding
the commenting problems: it is important for the reviewer or maintainer
or rereader to get the gist of the story. Much of the LilyPond codebase
has been written with a total disregard to people not present during the
writing.
Thank you for the _excellent_ review. This is _exactly_ the type of stuff I
need.
https://codereview.appspot.com/7185044/diff/32003/input/regression/tuplet-number-outside-staff-positioning.ly
File input/regression/tuplet-number-outside-staff-positioning.ly
(right):
On 1 févr. 2013, at 16:04, d...@gnu.org wrote:
As previously, there are no comments whatsoever putting the code into
perspective. This is an amorphous heap of code without an attempt of
explaining its design or inner logic. There is a single function
comment giving a glimpse of what that
On 2013/02/03 08:45:13, mike7 wrote:
On 1 févr. 2013, at 16:04, mailto:d...@gnu.org wrote:
As previously, there are no comments whatsoever putting the code
into
perspective. This is an amorphous heap of code without an attempt
of
explaining its design or inner logic. There is a
As previously, there are no comments whatsoever putting the code into
perspective. This is an amorphous heap of code without an attempt of
explaining its design or inner logic. There is a single function
comment giving a glimpse of what that function is supposed to do.
However, there is no
Hey all,
After letting this newest round sit for a few days, I'm pretty confident
that the patch is ready for review so I'd ask people to review it.
First, if anyone needs more comments in the code to let them know what's
going on, lemme know where and I'll add it. Second, if people have
People can review this if they have time...it is a lot of code, but it
is more a progress report than anything else.
To resume a bit of what's been said before: once translate_axis is
called, the dim_cache of grobs is set and it is very difficult to work
with approximations. This makes
On 28 janv. 2013, at 06:33, Keith OHara k-ohara5...@oco.net wrote:
On Sun, 27 Jan 2013 01:45:16 -0800, m...@mikesolomon.org
m...@mikesolomon.org wrote:
On 26 janv. 2013, at 23:21, k-ohara5...@oco.net wrote:
The tracker says the overall goal is to remove a call to the function
On 26 janv. 2013, at 23:21, k-ohara5...@oco.net wrote:
This would take me a couple more hours to figure out. Do I want to ?
It seems the caching is not the type that saves us from
re-computation. It simply stores the skylines Scheme objects.
Yup.
The tracker says the overall goal is
m...@mikesolomon.org m...@mikesolomon.org writes:
Maybe it's not worth it to do all this intermediate stuff...you're
right that it takes time for others to understand (and even for me to
understand) as I'm working towards this goal. The project is even
more ambitious as the last skyline one in
On 27 janv. 2013, at 11:51, d...@gnu.org wrote:
m...@mikesolomon.org m...@mikesolomon.org writes:
Maybe it's not worth it to do all this intermediate stuff...you're
right that it takes time for others to understand (and even for me to
understand) as I'm working towards this goal. The
On Sun, 27 Jan 2013 01:45:16 -0800, m...@mikesolomon.org m...@mikesolomon.org
wrote:
On 26 janv. 2013, at 23:21, k-ohara5...@oco.net wrote:
The tracker says the overall goal is to remove a call to the function
translate_axis. In the example
{ g4\ g'_pico g' g\! }
when we decide to move the
This would take me a couple more hours to figure out. Do I want to ?
It seems the caching is not the type that saves us from
re-computation. It simply stores the skylines Scheme objects.
The tracker says the overall goal is to remove a call to the function
translate_axis. In the example
{
38 matches
Mail list logo
