LGTM
Carl
http://codereview.appspot.com/4490045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/05/28 16:13:43, benko.pal wrote:
aargh, that's not too readable.
what I actually suggest is replacing lines 204-207 of
http://codereview.appspot.com/4490045/diff/12001/lily/completion-note-heads-engraver.cc
File lily/completion-note-heads-engraver.cc (right):
204 if
On 2011/05/29 08:53:30, benko.pal wrote:
I must miss something, to me it's still a boolean.
and (still to me) it's not an inline conditional, but
an assignment of a boolean expression to a boolean
variable.
No, it is I that missed something. I'm sorry for the noise.
Thanks,
Carl
The code looks fine in general, but I question two of the properties
that have been added for MultiMeasureRest.
http://codereview.appspot.com/4536068/diff/19001/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):
Do we need to change the definition of stem-attachment in
scm/define-grobs.scm to be ,boolean-or-number-pair? (and maybe define a
new ,boolean-or-number-pair predicate)?
Do we need to make any changes to ly/note-head-scheme.cc?
Do we need to check for #f in ly/note-collision.cc?
I just did a
IIRC, part of the motivation for the new spacing algorithm was the
desire to put staves in fixed positions on the page, regardless of what
else was around.
Does this patch eliminate this possibility? If so, is it possible to
disable it? I guess by setting padding to 0?
On 2011/05/25 18:08:59, Keith wrote:
On 2011/05/25 13:43:55, Carl wrote:
IIRC, part of the motivation for the new spacing algorithm was the
desire to
put
staves in fixed positions on the page, regardless of what else was
around.
Does this patch eliminate this possibility?
No.
On 2011/05/26 03:26:32, Keith wrote:
`make check` was crashing on an unbound variable 'note'. Given line
345 above
the fix was so obvious that I just pushed it.
Thanks for the fix. I had found that fix as well, and was getting ready
to push it. But there's still another problem. Right
http://codereview.appspot.com/4553056/diff/1/lily/text-interface.cc
File lily/text-interface.cc (right):
http://codereview.appspot.com/4553056/diff/1/lily/text-interface.cc#newcode40
lily/text-interface.cc:40: int max_length = scm_to_int
(ly_chain_assoc_get (ly_symbol2scm
On 2011/05/23 22:15:38, Bertrand Bordage wrote:
Yes.
Knowing this, I suggest we keep whitespaces, punctuation, quotes and
word
dividers (with some small changes).
There's still something that bothers me : isn't there some special
characters
that you can't do with you keyboard ?
Even on
On 2011/05/23 23:11:33, Bertrand Bordage wrote:
Making this easier should be the OS's job.
Yes, I agree. That's why I'm not in favor of making it part of LilyPond
for us to maintain.
Having the facility to do the general substitution as part of LilyPond
is fine, IMO.
Having the list of all
What if instead of setting a boolean stem-ignore, you just set
stem-attachment = ##f in order to get this behavior? This would be
consistent
with setting stencil = ##f in order to eliminate the stencil.
If you want to keep a separate boolean, I think I'd prefer the name
no-stem to stem-ignore.
This looks generally good to me.
I'm concerned about the name duration-log-list. I've commented more
on it below.
Thanks,
Carl
http://codereview.appspot.com/4536068/diff/1/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
LGTM.
Carl
http://codereview.appspot.com/4535055/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I didn't follow everything you've done, because I didn't have time to
look through it all in detail.
You should be aware, however, that the points for the tie are different
from the extents. The left end of a tie will be at t = -delta, rather
than at t=0. This is because of the width of the
Seems reasonable to me.
I couldn't think of any way to generalize the internal call.
Carl
http://codereview.appspot.com/4517051/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, with a small nitpick.
I like the new braces better.
Carl
http://codereview.appspot.com/4518052/diff/1/mf/feta-braces.mf
File mf/feta-braces.mf (right):
http://codereview.appspot.com/4518052/diff/1/mf/feta-braces.mf#newcode148
mf/feta-braces.mf:148: fatten_factor := 1.5;
I think that
Reviewers: MikeSol,
Message:
In response to Mike's request, I've fixed the problem in determine-frets
that sometimes changed the order of the notes in the chord.
This keeps the glissando between the same notes in the TabStaff as in
the Staff.
I've made enough changes that I'd like to get a
Looks mostly good to me.
Carl
http://codereview.appspot.com/4124056/diff/32001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4124056/diff/32001/Documentation/notation/input.itely#newcode667
LGTM.
I tried fixing this but couldn't track down all the interfaces to figure
it out. I saw that we were going off staff position rather than parent
position, but didn't know where to fix it.
Thanks!
http://codereview.appspot.com/4489042/
___
LGTM.
It wasn't necessary to remove \chordGlissando from the text of the
non-english docs, and it may even have been best not to do so.
We need to keep compiling working, so if these docs had a snippet
containing \chordGlissando, we would have needed to change that. But
since the snippet was
LGTM, with Neil's comments implemented.
http://codereview.appspot.com/4449061/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, although I'm not an expert on articulate.
http://codereview.appspot.com/4435069/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. A couple of non-essential comments.
http://codereview.appspot.com/4442083/diff/12001/input/regression/rest-polyphonic-2.ly
File input/regression/rest-polyphonic-2.ly (right):
http://codereview.appspot.com/4442083/diff/12001/input/regression/rest-polyphonic-2.ly#newcode5
LGTM.
http://codereview.appspot.com/4278058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
http://codereview.appspot.com/4457042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Regtest for 1640?
http://codereview.appspot.com/4457042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Looks good to me -- just a comment on a variable name.
http://codereview.appspot.com/4426072/diff/1001/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/4426072/diff/1001/lily/beam.cc#newcode1272
lily/beam.cc:1272: Interval vorboten;
We shouldn't use german words for
Excellent work!
A couple of comments below.
http://codereview.appspot.com/4442082/diff/3001/scm/define-context-properties.scm
File scm/define-context-properties.scm (right):
http://codereview.appspot.com/4442082/diff/3001/scm/define-context-properties.scm#newcode260
LGTM.
If I had done it I would have defined chordShapes for the common shapes
and moved them up and down the fretboard. But that's not necessary; I'd
totally support this addition.
Sorry I'm so slow on this -- I reviewed it a while ago and forgot to
comment.
Carl
The patch seems appropriate.
However, I think there should be more patches, IIUC. There are comments
in this file referring to being automatically generated. While this may
have been the original genesis of the file, since it's in
input/regression it's not automatically generated from out/*.
On 2011/04/14 22:52:04, reinhold_kainhofer.com wrote:
Yes, of course! As Graham wants to push Bertrand's patch on Saturday
morning,
I'll update my patch accordingly. As Bertrand's patch was already out,
I didn't
even try to include its functionality (but added the TODO comment as a
LGTM
Carl
http://codereview.appspot.com/4398046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
THe structure of the patch looks good, but I think it conflicts with
Bertrand's patch for 1605. Perhaps the two could be combined.
Thanks,
Carl
http://codereview.appspot.com/4398046/diff/1/scm/framework-ps.scm
File scm/framework-ps.scm (right):
I'd recommend that the new function be placed in scm/output-ps.scm
Thanks,
Carl
http://codereview.appspot.com/4377054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/04/12 13:33:05, Bertrand Bordage wrote:
How ? output-ps is dependant of framework-ps... When I move it to
output-ps, it
doesn't work.
Never mind. I don't know what I was thinking when I made that comment.
Sorry,
Carl
http://codereview.appspot.com/4377054/
Wow -- what a quick response! Thanks!
I have a couple of comments.
Carl
http://codereview.appspot.com/4385053/diff/1/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
http://codereview.appspot.com/4385053/diff/1/scm/define-grob-properties.scm#newcode61
Instead of adding a property, is there a way to just make the default
value of the property be staff_space?
Thanks,
Carl
http://codereview.appspot.com/4385053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Instead of adding a property, is there a way to just make the default
value of the property be staff_space?
Thanks,
Carl
http://codereview.appspot.com/4385053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Reviewers: ,
Message:
Marc Hohl has prepared a patch for mandolin predefined fretboards.
The patch looks good to me.
Please review.
Thanks,
Carl
http://codereview.appspot.com/4384055/diff/1/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely
LGTM.
Carl
http://codereview.appspot.com/4387046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
Carl
http://codereview.appspot.com/4385050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/04/10 02:47:42, Carl wrote:
LGTM
Carl
If you have push access, go ahead and push. If not, send it to me and
I'll push it.
No further review is necessary.
Thanks,
Carl
http://codereview.appspot.com/4385050/
___
lilypond-devel
Reviewers: ,
Message:
Here's a proposed patch for Issue 1569.
Please review.
Thanks,
Carl
Description:
Fix 1569: Bad behavior of NoteNames context
Changed default value of 'staff-affinity to #UP
Changed default spacing parameters to be the same as for Lyrics
context
Added some
LGTM.
Carl
http://codereview.appspot.com/4273074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
Carl
http://codereview.appspot.com/4243071/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Also, it's a simple enough change that I don't think any discussion is
necessary. We should go ahead and push it. It's just a change of a
single constant value.
Carl
http://codereview.appspot.com/4243071/
___
lilypond-devel mailing list
LGTM
Carl
http://codereview.appspot.com/4237059/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
Thanks,
Carl
http://codereview.appspot.com/4239048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
Thanks,
Carl
P.S. Can you propose your patch to git-cl to the git-cl maintainers? I
think that your approach is the right one. But I don't want to have us
in the position of needing a custom git-cl.
http://codereview.appspot.com/4176056/
On 2011/02/26 20:01:39, Colin Campbell wrote:
I like that very much, James, thanks! A question for Reinhold,
though: do I
gather correctly that \partcombine is applied to a Staff, and turns
the
combining mechanism on, while \partcombineAutomatic is applied to a
single
Voice? That being
On 2011/02/17 16:17:29, nicolas.sceaux wrote:
Hi,
Here is a patch for fret diagrams, but as I have very little knowledge
of them I
may well be wrong on some points.
First, it fixes sizing issues, when the size property is overridden:
the xo
signs became too big, and too far from the
This work looks good to me, but I'm not an expert in this area.
I have one question, I think. Right now, the alteration consists of two
integers, which have implied denominators of 1/2 and 1/4, if I
understand correctly.
Would it be more general to have the alteration consist of two
rationals?
Looks very good.
Just a couple more comments.
Thanks,
Carl
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode994
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode994
scm/define-markup-commands.scm:994: (define (nest-patterns pattern
pattern-width
Looks good. I had one comment.
Feel free to add an entry to the changelog. It's done by editing the
file Documentation/changes.tely
Thanks,
Carl
http://codereview.appspot.com/4182056/diff/7001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
On 2011/02/15 07:15:48, Trevor Daniels wrote:
http://codereview.appspot.com/4160048/diff/5001/Documentation/notation/rhythms.itely#newcode2211
Documentation/notation/rhythms.itely:2211: To avoid this problem, the
time
signature can be set in only one
I still prefer should
I don't want to
Updated patch set posted for review.
THanks,
Carl
http://codereview.appspot.com/4160048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I like the idea.
I think to become part of the distribution it needs to support both
postscript and svg.
Thanks,
Carl
http://codereview.appspot.com/4172047/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
LGTM
Carl
http://codereview.appspot.com/4186050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/02/15 00:27:35, Felipe wrote:
http://codereview.appspot.com/4160048/diff/5001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):
http://codereview.appspot.com/4160048/diff/5001/Documentation/notation/rhythms.itely#newcode2207
LGTM.
Thanks, Keith!
Carl
http://codereview.appspot.com/4187043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Mats identified some unexpected behavior with autobeam settings and time
signature setting.
http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/23117
This patch demonstrates the problem, describes the reason, and documents
two ways of avoiding the problem.
Please review
On 2011/02/02 23:55:59, Neil Puttock wrote:
LGTM.
Just needs rebasing (I assume you don't want to delete
tablature-dot-placement.ly)
Done
http://codereview.appspot.com/4056041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On 2011/01/31 19:36:16, Keith wrote:
On 2011/01/31 11:20:39, hanwenn wrote:
* this hardcodes 0.1 in several places. Make a property,
so we can override this
Agreed in principle; the relevant property extra-spacing-height should
absorb
these magic numbers, but I am not willing to do so in
This patch solves Neil's problem with clef spacing.
LGTM.
Carl
http://codereview.appspot.com/4095041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/01/25 13:57:32, Graham Percival wrote:
Pushed.
cb03a19174fd9245008176716742e1a2eb3a0b93
Thanks,
Carl
http://codereview.appspot.com/4061043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
I can't comment on the appropriateness of the makefile stuff.
Everything else looks good to me.
Does this match up with the Gonville font stuff that was included
earlier on the LSR? We probably ought to put Gonville and
lilyjazzchords in the same parent directory.
On 2011/01/24 21:27:35, benko.pal wrote:
new patchset up.
please advise me about regression tests: can I modify ligatures within
mensural-ligatures.ly? if not, can I add new ones to the same file?
Ancient music has been abandoned by developers for a number of years.
IMO, you may do
On 2011/01/24 16:33:22, Graham Percival wrote:
Almost there.
Could you run makelsr and then don't forget to do
git add Documentation/snippets/*.ly
Done, and new patch set uploaded.
Thanks,
Carl
http://codereview.appspot.com/4061043/
___
This patch also resolves the problem in issue 1229 of notes extending
beyond the right-hand bar line.
Adding additional extra-spacing-height to the TimeSignature grob
resolves the 1229 issue of overlapping the time signature.
This patch seems to have some very good benefits.
On 2011/01/23 09:09:09, Trevor Daniels wrote:
I think the templates would be improved with
system-system-spacing #'basic-distance = #20
added to \paper. Otherwise the bass lyrics will be too
close to the soprano lyrics on the following system.
Done. I also added top-system-spacing and
I've responded to the comments in detail below.
Graham, relative to your comments on issues 1483 and 1486, both are
addressed in this patch.
The templates now have the lyrics attached properly to the staves, as do
the examples in the NR. This takes care of 1483.
The templates also have
LGTM.
Carl
http://codereview.appspot.com/212048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Let me start by saying I know *nothing* about mensural notation.
The code looks good to me.
I found only one real issue:
LilyPond coding standards for C++ say that if there is only one
statement in an if clause, we omit {} around that clause.
I also had a question (and it probably doesn't
LGTM.
Carl
http://codereview.appspot.com/4099044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
New patch set uploaded.
http://codereview.appspot.com/3928041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Great start, James!
Getting this far is more than half the battle.
Are you up for the next round of changes now?
Thanks,
Carl
http://codereview.appspot.com/4005046/diff/1/ly/declarations-init.ly
File ly/declarations-init.ly (right):
Reviewers: ,
Message:
Here is a potential patch for fixing the lyric spacing regressions.
It updates the documentation to clarify what is needed to make lyrics
behave as desired.
It also adds a snippet that demonstrates how to achieve the old spacing
behavior.
Please respond with any
Thanks, Marc. Good suggestion.
http://codereview.appspot.com/4056041/diff/1/scm/translation-functions.scm
File scm/translation-functions.scm (right):
http://codereview.appspot.com/4056041/diff/1/scm/translation-functions.scm#newcode394
scm/translation-functions.scm:394: ((eq? handle-negative
Reviewers: marc,
Message:
I've posted a patch for fixing issue 1035, by giving the user control
over
what to do with negative fret numbers demanded by an assigned string.
The default behavior is to recalculate the note and put it in the
tablature or fretboard as if it had not had a string
LGTM.
Thanks,
Carl
http://codereview.appspot.com/3992042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Looks very good to me.
I'd like to see the property name changed to extra-stem-length.
Thanks,
Carl
http://codereview.appspot.com/3934041/diff/11001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/3934041/diff/11001/lily/stem.cc#newcode322
lily/stem.cc:322: Real
Reviewers: MikeSol,
Message:
Looks great, Mike!
You have some code indentation issues that don't match our style. Other
than that, I think it's good to go.
Of course, we do need a regression test as well.
Thanks,
Carl
Latest patch set uploaded with full side-by-side-diffs.
Thanks,
Carl
http://codereview.appspot.com/3928041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
Don't forget to fix your copyright on beam-collision-engraver.
One set of braces to be removed.
Thanks,
Carl
http://codereview.appspot.com/3928041/diff/17001/lily/beam-collision-engraver.cc
File lily/beam-collision-engraver.cc (right):
New patches pushed.
Thanks,
Carl
http://codereview.appspot.com/3928041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
Carl
http://codereview.appspot.com/3934041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I've added comments about the need for the horizontal-padding in the
distance call to be used with System grobs, and I've moved the
skyline-horizontal-padding from an override to a default value for the
System grob.
I think this should make everything work right out of the box now,
without
Thanks for the feedback. I've responded to each of the suggestions
you've given me.
Carl
http://codereview.appspot.com/3832046/diff/27001/input/regression/skyline-horizontal-padding.ly
File input/regression/skyline-horizontal-padding.ly (right):
On 2011/01/07 21:41:51, Neil Puttock wrote:
Hi Carl,
Do we have to set a default for skyline-horizontal-padding? It has a
detrimental effect on some of the regtests (particularly
stem-length-estimation.ly).
I've set the default to 0.5, in accordance with Keith's suggestions. It
leaves
Thanks, Keith for identifying the problem with bar numbers at the
beginning of the line.
I've fixed that problem, and I'm more confident in the logic of the box
extraction and padded skyline creation.
I've modified the regression test so it has 3 systems, and thus would
catch the problem that
I've made the changes, and now the patch actually works.
Thanks all for your comments!
Carl
http://codereview.appspot.com/3832046/diff/2001/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):
On 2011/01/04 01:46:45, Keith wrote:
For a 2-staff system
(with non-protruding bass clefs to make the math easier) the patch
computes
minimum_distance
3.05, 7.33, 29.41, 29.38
as it adds four systems to a page.
Can you send me a test file so I can check it out?
Thanks,
Carl
Thanks for all the comments.
Keith has identified the correct place to put include the system
horizontal padding, and it now works properly.
New patch set coming shortly.
Carl
http://codereview.appspot.com/3832046/diff/2001/input/regression/skyline-horizontal-padding.ly
File
Reviewers: ,
Message:
Here is a patch to fix issue 1290.
It works, but it may need to be cleaned up. I'm not sure the code is as
elegant as it could be. I'm not really comfortable with all of the C++
syntax used in lilypond.
Please review it carefully, and let me know how it can be improved.
On 2010/12/29 05:18:07, Keith wrote:
Agreed. My earlier 'arbitrary' was a mental slip. I was thinking the
choice was
sensible, but even if it were arbitrary I would be scared of change.
The order for the chord entry was requested by the users. Chords
are
generally
entered lowest note
On 2010/12/29 05:18:07, Keith wrote:
ly/string-tunings-init.ly:43: (make-music 'SequentialMusic 'void #t)))
We need to save the string tuning in a Scheme variable...
But if it is possible to set the variable as you do now, and then
return a
PropertySet instead of the void event,
(begin
I've responded to all the commandments and put up a new patch.
Thanks for all of your input.
Please review.
Carl
http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
On 2010/12/29 02:25:44, Keith wrote:
I'm not a programmer, but accustomed to doing code review as a systems
engineer.
I very much appreciate the review. Thanks!
Change stringTunings entries from semitones to pitches
This lays the foundation for creating a TabKey grob
Presumably the
301 - 400 of 1173 matches
Mail list logo
