Re: Pre-review questions about image(s) and translations
On Wed, Jan 15, 2014 at 10:15 AM, Urs Liska wrote: > Am 15.01.2014 16:13, schrieb Paul Morris: > > Urs Liska wrote >> >>> a) in what form should I provide such an image that it can be translated >>> and modified in the future? >>> >> >> Since your image is simply boxes with text and arrows connecting them, one >> possibility might be to do it with html and css rather than making it an >> image. The styling and layout of the boxes would be straightforward and >> the >> arrows could be background images. I would think that that would make it >> simpler to localize the text. >> >> But I don't know if and how the texidoc generation of html would work for >> this. >> >> -Paul >> >> > Sounds good. Anyone with a clear idea about this texidoc-wise? > > Urs Maybe not texidoc-wise, but it's something I thought about on its own merits. I'm personally not crazy about is as it would basically result in us creating a very specialized set of CSS parameters for a very specific thing that could be changed and completely removed or made incompatible with what is coded. That said, Paul is right. It is technically doable (and in a way that gracefully degrades to text browsers), but I'm not sure that's the ideal route from the maintenance side of things. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Pre-review questions about image(s) and translations
On Tue, Jan 14, 2014 at 11:51 AM, Urs Liska wrote: > > > As you can see I have created a flowchart to visualize the relation > between the different parts of the editing cycle. > > If it were simple the two PNG files I knew that I would have to add them > to lilypond-extra and open a pull request so Graham could add it there. > But: This image is generated with LaTeX and contains text that should be > localized. > > So: > a) in what form should I provide such an image that it can be > translated and modified in the future? I.e. I would prefer to add the .tex > source somewhere and have some automated way to process it (including the > conversion to PNG which I've done manually for now). > b) is there a way to provide a way to generate vector versions for use in > the PDF manuals? > > Urs > My first instinct is to prepare an SVG file that could be processed with inkscape or another program as part of the make process. I think I read in the discussion of the 2.18 cheat sheets that there's a way to do localized strings for SVG files. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for January 15th - 06:00 GMT
On Sun, Jan 12, 2014 at 1:34 AM, James wrote:
> Hello
>
> The following patches have been at 'please push' for the last 3 countdowns
> (i.e. over 9 days), and I am not seeing anything obvious that leads me to
> believe that their is 'Needs Work' on them. I am seeing recent emails from
> them on the lists and so assume they would also be getting the tracker
> emails too.
>
>
> 3753<http://code.google.com/p/lilypond/issues/detail?id=3753&q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-push&sort=patch&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified>
> Enhancement
> Carl Peterson push Patch: Cleanup of ugly MI and SOL shaped noteheads
>
>
>
>
> Patch attached, if someone can push. I apologize for the delay...I haven't
had my dev machine on for a bit now, so just now getting this together.
Regards,
Carl P.
From 85438eca8044ed67a207e2163dca959df6986df8 Mon Sep 17 00:00:00 2001
From: Carl Peterson
Date: Mon, 23 Dec 2013 17:04:13 -0500
Subject: [PATCH] Cleanup of ugly MI and SOL shaped noteheads
1. Reducing width of MI notehead, for both "regular" (Aiken, etc.)
and "small" (Funk/Walker) heads. When Funk/Walker heads were
introduced, a special width variable was introduced to both
sets and the mi heads were made wider than the other noteheads.
This does not seem to be the practice of available examples
(Sacred Harp, Southern Harmony books, etc.) and causes issues
with alignment, particularly with stems up, and is visually odd.
The variables have been removed from the metafont code, making
the MI noteheads the same width as the other shaped notes in
their respective sets.
2. Changing the SOL notehead to more closely match the normal round
notehead (as advertised in the mf code). The previous code uses
the shape of the open (half note) notehead, which is visually
unappealing. The open notehead has been defined so that it
matches visually with both the normal Aiken/Sacred Harp heads,
as well as the thin variants (in keeping with observed practice,
which uses the regular open roundhead even when thin variants
are used).
---
mf/feta-noteheads.mf | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/mf/feta-noteheads.mf b/mf/feta-noteheads.mf
index 2ebf537..6881837 100644
--- a/mf/feta-noteheads.mf
+++ b/mf/feta-noteheads.mf
@@ -1222,66 +1222,65 @@ def draw_mi_head (expr width_factor, thickness_factor, mirror) =
enddef;
-save mi_weight, mi_width;
+save mi_weight;
mi_weight := 2;
-mi_width := 1.2;
fet_beginchar ("Whole mihead", "s0mi");
- draw_mi_head (mi_width * solfa_whole_width, mi_weight, false);
+ draw_mi_head (solfa_whole_width, mi_weight, false);
fill path_out;
unfill path_in;
fet_endchar;
fet_beginchar ("Half mihead", "s1mi");
- draw_mi_head (mi_width * solfa_quarter_width, mi_weight, false);
+ draw_mi_head (solfa_quarter_width, mi_weight, false);
fill path_out;
unfill path_in;
fet_endchar;
fet_beginchar ("Quarter mihead", "s2mi");
- draw_mi_head (mi_width * solfa_quarter_width, mi_weight, false);
+ draw_mi_head (solfa_quarter_width, mi_weight, false);
fill path_out;
fet_endchar;
fet_beginchar ("Whole mirror mihead", "s0miMirror");
- draw_mi_head (mi_width * solfa_whole_width, mi_weight, true);
+ draw_mi_head (solfa_whole_width, mi_weight, true);
fill path_out;
unfill path_in;
fet_endchar;
fet_beginchar ("Half mirror mihead", "s1miMirror");
- draw_mi_head (mi_width * solfa_quarter_width, mi_weight, true);
+ draw_mi_head (solfa_quarter_width, mi_weight, true);
fill path_out;
unfill path_in;
fet_endchar;
fet_beginchar ("Quarter mirror mihead", "s2miMirror");
- draw_mi_head (mi_width * solfa_quarter_width, mi_weight, true);
+ draw_mi_head (solfa_quarter_width, mi_weight, true);
fill path_out;
fet_endchar;
fet_beginchar ("Whole thin mihead", "s0miThin");
- draw_mi_head (mi_width * solfa_whole_width, 1, false);
+ draw_mi_head (solfa_whole_width, 1, false);
fill path_out;
unfill path_in;
fet_endchar;
fet_beginchar ("Half thin mihead", "s1miThin");
- draw_mi_head (mi_width * solfa_quarter_width, 1, false);
+ draw_mi_head (solfa_quarter_width, 1, false);
fill path_out;
unfill path_in;
fet_endchar;
fet_beginchar ("Quarter thin mihead", "s2miThin");
- draw_mi_head (mi_width * solfa_quarter_width, 1, false);
+ draw_mi_head (solfa_quarter_width, 1, false);
fill path_out;
fet_endchar;
@@ -1446,9 +1445,10 @@ fet_endchar;
% so we can't just use the standard note font.
%
def draw_sol_head (expr
Re: 3.0?
On Sat, Jan 11, 2014 at 11:50 PM, Paul Morris wrote: > Carl Sorensen-3 wrote > > I can't speak for Carl P's work. For me, effective LP input files > require > > structure (variables, contexts) that MusicXML knows nothing of. And it's > > generally easier to create them than to fix them on import. > > I see what you mean. Unfortunately it makes it harder to use other tools > that are optimized for composing with LilyPond... Seems like capturing > just > the musical content from a MusicXML file and then pasting it into a LP > template or file that has the LP structure should be easier than re-typing > it. But I defer to those with more experience in this area, as I've only > done musicXML import a few times. > > Urs Liska wrote > > https://github.com/wbsoft/frescobaldi/issues/345 > > I'm not sure about this. Seems like you could get basically the same > workflow by using a second file as a sketchpad without having to introduce > a > new UI component. See my comment at the link above for more of my thoughts > on this. > > -Paul > > Allow me to extend my use case a bit further. My own work is similar to what I understand of Carl S's work. I have a file where I define each of my SATB parts, each lyrical verse, and calls a template file that takes the parts and creates the two staves for the music, with both a part-combined voice for display purposes and separated voices for MIDI and lyric purposes (the separated notes are hidden and non-colliding, etc., in the layout). I have a second file where I include this "master" file and create either the paper hymnal layout or slides for projection (depending upon which layout template I call). I've done the two file workflow before, typically when I've created the four parts using a basic SATB template, then copied and pasted into the variables of my own template. That said, I am also trying to think about features which would make this more productive for someone who *isn't* inclined to work multiple files, variables, etc. What I would *ultimately* like is the ability for someone to visually write each part on separate staves (or using two staves with two voices each), then those parts are translated into the template without any direct code manipulation. The visual interface would be like the single-line view in Finale (where it's not trying to deal with line lengths/spacing, etc.). This is basically what I do in MuseScore or Finale Notepad from the compositional side, but I'm trying to find the most efficient workflow to go from that to my template. I don't know if it's practical, possible, or what. I don't know whether this would be a Frescobaldi thing or a Denemo thing. Since Denemo is already a GUI experience, it may be the better place to try to get this kind of functionality. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Fri, Jan 10, 2014 at 4:25 PM, Urs Liska wrote: > > Well, > compiling a few measures of a single staff feels nearly instantaneous, and > when you're editing an orchestral score this makes a huge difference. > > Generally I'd think it would be a good idea to have such an interface in > Frescobaldi. UI-wise it wouldn't be too hard to add that. However, there is > one thing I've thought about several times and that doesn't make the issue > so easy: > If you have a short segment of a score, say in a variable, how can you > guarantee that LilyPond has the right context for that (I'm not talking of > \context, but of things like key, time signature, transposition etc.)? > > Couple of possibilities. Just thinking about Frescobaldi, since it seems to do a pretty good job of tracing things through the document(s), would it be possible to look for the reference to that variable and try to determine the context? Another option is that this is not a "compilation" feature (i.e., Fresco is not passing the variable to LP to compile), but rather it would allow a dialog box/popup and there would be the option to change certain things like time signature, transposition, etc. I actually think it should be some kind of bare-bones parser apart from LP proper (a bypass) that doesn't factor in articulations, manual tweaks, etc., but only considers absolutely essential components (notes, slurs, ties, chords, etc.). Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Fri, Jan 10, 2014 at 12:46 AM, Paul Morris wrote: > Carl Peterson wrote > > I use MuseScore, > > Scorio, and Finale Notepad (depending on where I am and how I feel) > > for compositional work because they provide ease of note entry in the > > composing process and the ability to have instant aural feedback on > > what I've written (particularly if I'm not at my keyboard to play what > > I've written). Once I have the draft of the music written, I will > > manually retype the music into my LilyPond template because of the > > "good default typesetting" it provides. > > Hi Carl, Do you find that manually retyping is easier or better than > export > -> musicXML -> import? Curious to hear your thoughts as I would assume > that > import/export would be the ideal way to use a workflow like this. > > Retyping by far. I pretty much write exclusively a cappella SATB, and I have developed a very specific template/workflow for the part combining and layout. I've tried a few different ways of getting the music from these formats into LP, and in each case, I found myself spending longer in cleaning up the resulting LilyPond code than if I had just transcribed it manually from the other program. That is why I suggested an IDE feature that would allow for creating a variable, and then providing a basic visual note-entry tool that can handle single or chorded notes (whether it allows polyphonic music may be a more challenging question), then return minimal code (just the notes). I know someone suggested just turning off the PDF conversion to speed things up, but it's not just a matter of instantaneous aural feedback. There's a visual component and a matter of input error reduction, because I have been known to enter incorrect octaves or durations and not realize it until I've finished typing and have compiled the entire score. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
On Thu, Jan 9, 2014 at 6:20 AM, David Kastrup wrote: > Another problem is that LilyPond has a usage philosophy and workflow > that strongly penalizes manual tweaks. Graphically/manually oriented > workflows detract from the importance of getting good default > typesetting. I don't know that I agree with this, entirely. I use MuseScore, Scorio, and Finale Notepad (depending on where I am and how I feel) for compositional work because they provide ease of note entry in the composing process and the ability to have instant aural feedback on what I've written (particularly if I'm not at my keyboard to play what I've written). Once I have the draft of the music written, I will manually retype the music into my LilyPond template because of the "good default typesetting" it provides. Now, consider an IDE/GUI setup (perhaps an extension of Frescobaldi) that would allow me to define a variable for a voice, then pop up a musical staff to enter and play back the notes for that variable without dealing with the whole compilation process. No manual tweaking of notes, just the entry of the entry and playback of the notes, and I don't have to insert the notes into the music itself yet or deal with whatever may or may not be wrong with the rest of my file. I realize that this would not necessarily work for all use cases, but I think for a large number of them, this could be beneficial. It would reduce a number of my transcription errors without me having to compile, scan for errors, potentially figure out where the errors are (depending on workflow), correct, recompile, etc. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Introduction: Rename "Our Goal" box (issue 48430043)
On Tue, Jan 7, 2014 at 9:16 AM, Phil Holmes wrote: > - Original Message - From: "Urs Liska" > > >>> I believe I had suggested "purpose." I realize that's not much better >>> than goal/mission, but it's less corporate than "mission," and is more >>> focused on why we exist than what we think we've accomplished (as goal >>> and objective are), in my opinion. >>> >>> Carl P. >>> >> >> Yes I recall that. For me this somehow sounds wrong - but again that may >> be due to my non-native "ear". >> Phil, what do you think about "purpose"? >> >> Urs > > > > To me, it's a very uninspiring word. NASA had a goal of landing a man on > the moon (http://history.nasa.gov/moondec.html). Its purpose was much more > mundane. > > -- > Phil Holmes Would "vision" be better? I realize this will sound to some people as corporate as "mission," but there you go. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Introduction: Rename "Our Goal" box (issue 48430043)
On Tue, Jan 7, 2014 at 8:34 AM, Urs Liska wrote: > Am 07.01.2014 14:32, schrieb Carl Sorensen: > >> >> On Jan 7, 2014, at 3:56 AM, "Phil Holmes" wrote: >> >>> - Original Message - From: >>> To: >>> Cc: ; >>> Sent: Tuesday, January 07, 2014 10:45 AM >>> Subject: Re: Web:Introduction: Rename "Our Goal" box (issue 48430043) >>> Any other suggestions? >>> >>> >>> "Our goal" :-) No less achieved than a mission. >>> >> >> Intent >> Object >> Ambition >> Desire >> Hope >> Plan >> Aim >> >> >> Carl > > > Thanks for the suggestions. But I'm afraid only the first three would be > appropriate at all, and even these aren't better than "Goal" or "Mission" or > "Objective". > > I've uploaded a second patchset with David's "Objective" suggestion, but I'm > nearly ready to revert it to "Goal" after Phil's last email. > > Urs I believe I had suggested "purpose." I realize that's not much better than goal/mission, but it's less corporate than "mission," and is more focused on why we exist than what we think we've accomplished (as goal and objective are), in my opinion. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: License of files in Documentation/pictures and ability to distribute them unclear
On Sat, Jan 4, 2014 at 10:51 PM, Graham Percival wrote: > On Fri, Jan 03, 2014 at 03:28:22PM -0800, Don Armstrong wrote: >> It's great that a lot of them have the source which they were built from >> present, but there are some which are still missing the source. [For >> example, logo-debian.png can (and probably should) be built directly >> from the SVG[2] at the appropriate size (or just the SVG used).] > > Due to our website hosting situation, it would be awkward to build > it directly. As for SVG, I'm not familiar with browser and > texinfo support. We still have something like 50% users on > windows; can IE display SVGs yet? Also, can texinfo 4.13a handle > SVGs? SVG support in browsers is still incomplete, last I checked. IE9 has partial support, according to Wikipedia's article on SVG. Regardless, it's not ideal. Nor is live building practical, for the reason Graham mentioned (it would require running a server-side script with every image request to see if the image is available, build the image if necessary, then serve the image). However, an alternative would be to somehow build the SVG to PNG at the expected size(s) as part of make. Not sure what that would take, though, or if it would add yet another dependency to the list. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LILY-GIT PITA
On Wed, Jan 1, 2014 at 10:12 AM, James wrote: > On 07/12/13 18:33, Carl Sorensen wrote: >> I've thought of some possible fixes: >> >> 1) Add an "expert mode" button that then would open up a listbox that >> would allow you to choose your branch. >> >> 2) Create a special, branch-unaware version of lily-git.tcl that would >> always work on the current branch. >> >> 3) Create some special shell commands that will do just what you want, and >> give them to you directly. >> >> At the moment, I'm leaning towards 3, as it's the least-effort way to go. >> >> What do you think? >> >> Thanks, >> >> Carl >> Just now seeing this (I don't think I was subscribed when Carl S. wrote this). After my recent experience with lily-git.tcl and submitting a patch, one thing I would request is that, if possible, some kind of automatic line wrapping be built into its processing of the commit message (i.e., if a line exceeds n characters, go back to the last space prior to the nth character and replace with a line break). This will avoid the issue of poorly wrapped lines, which both David K and Janek have messaged me about. I don't recall that particular point being discussed in the CG. While it is certainly better to line break by hand, this would at least provide some degree of a "fail safe" against what I did as an uninformed new contributor. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Content of "Introduction"->"Our Goal"
On Wed, Jan 1, 2014 at 5:16 PM, Urs Liska wrote: > Am 01.01.2014 18:34, schrieb Phil Holmes: > >> - Original Message - From: "Urs Liska" >> To: "LilyPond Development Team" >> Sent: Wednesday, January 01, 2014 5:03 PM >> Subject: Content of "Introduction"->"Our Goal" >> >> [snip] >> >> I think the sentence could be: >> >> "The result is a system which frees composers from the details of >> layout, allowing them to focus on creating music." >> >> and would be completely clear. >> >> -- >> Phil Holmes > > > Completely clear, yes. But only fully appropriate if composers typesetting > their music while composing were LilyPond's core target audience/use case. > > Urs +1, speaking as a composer who composes in MuseScore for the convenience of audio feedback, then transcribes the music by hand into my LilyPond template to get the output I want. To the question about what to call it, I think "Our Purpose" is perhaps what you're wanting. As to what to say, The result is a program that creates printed music more closely resembling and following the best traditions of classical music engraving. This allows composers, transcribers and publishers to create publication-quality music---beautiful music---without having to spend as much time fighting the software's default settings. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleanup of ugly MI and SOL shaped noteheads (issue 45160043)
On Tue, Dec 31, 2013 at 12:29 PM, wrote: > On 2013/12/24 23:22:00, Carl P. wrote: > >> This may well need to happen. As I said, I've tried a few times over > > the >> >> last 8 or 9 months to inquire about the mi head particulary, with no >> response. > > > If you're the only person on the lists who cares, then you should be > able to have it the way you want it. > > I'm curious, though, about the usage in chords. In particular, it seems > that chords in Walker notes can't possibly line up, since do is centered > on the stem. Are chords commonly used in shape notes? Every reference > I've seen has no chords -- only single notes. Depending upon the style sheet, shaped notes have varying usage in chords. Even in single-note formats (Sacred Harp, Southern Harmony, etc.), there are examples of two notes being given for one part (optional octaves or providing a second note to complete the chord, typically SOL). For my own work, notes are nearly always written in chords, unless the notes are less than a third apart or there is a difference in rhythm. LilyPond's implementation of chords with Walker is to center the stem if the notehead nearest the stem is DO or to act normally otherwise. > > I'm fine to have this pushed if nobody else objects. But I do like > David K.'s suggestion of a message on -user with before and after > shapes. > I have sample PDFs I generated showing before and after, both singly and in chords. I haven't yet had time to convert/compress those examples to smaller file sizes for sending to -user, but hope to in the next couple of days. In the meantime, I'll probably take the patch off the countdown. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleanup of ugly MI and SOL shaped noteheads (issue 45160043)
On Dec 24, 2013 5:57 PM, wrote: > > The extra width on the "ugly" mi notes was a specific design decision > that was made in conjunction with the shape note community at the time > (see https://code.google.com/p/lilypond/issues/detail?id=1060). > I've wondered this, but I had been unable to determine this conclusively, and the couple of queries I had posted to the user list previously went unanswered. I understand the design choice, since I have observed this as well. I think most obvious cause of that optical choice is the relative size of the sol head, which is somewhat lessened by use of the conventional ellipse shape that is also in this patch. That said, the impression I get from looking at the sol head in a chord with other shapes is that it looks "droopy," as if the ellipse is being weighed down. What is interesting is that the print examples (most from the previous 30 years) do not have wider mi heads, but do not give me the impression of an optically smaller head (a phenomenon that is interesting given that if rounded corners are not considered, the Aiken mi head has an equal area to the aiken do and fa heads. Perhaps the answer may lie in a slight bowing of the edges (but not enough to confuse with sol)? The problem I have (and what drew me to a redesign) is that the wideness of the mi head causes alignment issues, particularly in chords. For instance, when mi is stacked on do, the points do not line up. In multi-staff settings, if mi is attached to an up stem, the extra width causes the other notes attached to that stem to be misaligned from the notes in other staves (something that I personally give Finale users grief about when they don't make sure simultaneous notes are absolutely aligned. > It may be correct to eliminate the extra mi width, but I don't believe > it should be done without review of a broader piece of the shape-note > community. > This may well need to happen. As I said, I've tried a few times over the last 8 or 9 months to inquire about the mi head particulary, with no response. > Carl S. > > https://codereview.appspot.com/45160043/ Thanks, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problems with git cl
On Tue, Dec 24, 2013 at 7:31 AM, James wrote: > Hello, > Is 'git-cl upload master' (which works for me) the same as 'git-cl upload > origin/master'? > I received the same error either way. > This error sounds familiar to me anyway :) > > Are you using Lily-git.tcl? > I have been, intermixed with command line usage. But again, my first patch review worked fine, and I was using lily-git.tcl exclusively. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Problems with git cl
Trying to upload a follow-up patch for my notehead change. When I try to run "git cl upload origin/master," I get fatal: ref HEAD is not a symbolic ref Command "git symbolic-ref HEAD" failed What am I doing wrong? Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Issue 3714 in lilypond: website: use colors to distinguish each manual and stable vs. development
On Sat, Dec 21, 2013 at 5:51 AM, David Kastrup wrote: >> Pushed them to staging. Can you try word wrapping the lines of the >> commit messages next time? I noticed this only after pushing. > If > you actually fix previous aspects of the _same_ patch series, you should > likely reorganize the series with > > git rebase -i > > before pushing: there is nothing gained by leaving a history of mistakes > and corrections in a patch series: try to organize it as though you got > everything right in the first try. Splitting a patch series into > separate patches should not be based on history but rather on splitting > the patch into logically distinct parts/steps. > > Thanks! Thanks for the feedback. Admittedly, I was using the lily-git.tcl since I hadn't really worked with git repos before. Now that I have done some experience (and am switching to git for some of my personal files), I might have a better chance of getting it right going at it from the command line. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: Issue 3714 in lilypond: website: use colors to distinguish each manual and stable vs. development
-- Forwarded message --
From:
Date: Thu, Dec 19, 2013 at 5:33 AM
Subject: Re: Issue 3714 in lilypond: website: use colors to
distinguish each manual and stable vs. development
To: carlopeter...@gmail.com
Updates:
Labels: -Patch-countdown Patch-push
Comment #15 on issue 3714 by pkx166h: website: use colors to
distinguish each manual and stable vs. development
http://code.google.com/p/lilypond/issues/detail?id=3714
Path counted down - please push. Carlo, I don't know if you have push
access, if not can you make a git formatted patch based on current
master and someone can push it for you.
Patches attached. Can someone push?
Thanks,
Carl P.
From a3c461efca539350e3da4f25423895bbf6f78519 Mon Sep 17 00:00:00 2001
From: Carl Peterson
Date: Sun, 8 Dec 2013 11:44:08 -0500
Subject: [PATCH 1/5] Add classes to tag of documentation files
To facilitate request from lilypond-user to facilitate differentiating among the various manuals, appending CSS classes to the tag of the documentation files so that the main CSS stylesheet can be modified to look for those classes to specifically style each manual and development status.
The present solution for indicating development status is a hardcoded line in Documentation/lilypond-texi2html.init.
---
Documentation/lilypond-texi2html.init |7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/lilypond-texi2html.init b/Documentation/lilypond-texi2html.init
index 0f0a94c..fbd7f14 100644
--- a/Documentation/lilypond-texi2html.init
+++ b/Documentation/lilypond-texi2html.init
@@ -1094,6 +1094,13 @@ sub lilypond_css_lines ($$)
$Texi2HTML::THISDOC{'CSS_LINES'} .= "\n";
}
}
+
+my ($docu_dir, $docu_name) = split_texi_filename ($Texi2HTML::THISDOC{'input_file_name'});
+
+$documentstatus = 'devStatus';
+
+$Texi2HTML::Config::BODYTEXT = 'lang="' . $Texi2HTML::THISDOC{current_lang} . '" class="' . $docu_name . ' ' . $documentstatus . '"';
+
}
--
1.7.10.4
From 95ce350d867750d8dd4fea95f72ed96da3e7cd28 Mon Sep 17 00:00:00 2001
From: Carl Peterson
Date: Sun, 8 Dec 2013 19:20:03 -0500
Subject: [PATCH 2/5] CSS changes to color-code major manuals
Added styling to use a manual-specific class in the tag to color code each of the major manuals.
Now:
* Learning Manual: Green book
* Notation Reference: Blue book
* Usage Manual: Yellow book
* Extending: Red book
* Internals Reference: Purple book
* Contributor's Guide: Black book
---
Documentation/css/lilypond-manuals.css | 100 +---
1 file changed, 93 insertions(+), 7 deletions(-)
diff --git a/Documentation/css/lilypond-manuals.css b/Documentation/css/lilypond-manuals.css
index 995c217..16dbbb3 100644
--- a/Documentation/css/lilypond-manuals.css
+++ b/Documentation/css/lilypond-manuals.css
@@ -1,4 +1,28 @@
/**/
+/* GENERAL INFORMATION */
+/**/
+
+/* It has been requested that each web manual be styled using a
+ different color. To faciliate that, each manual is being
+ assigned a hue value on the HSB color chart. All specific
+ colors for a manual will be shades and tints of that hue.
+
+ ManualColor Hue
+ learning green 120
+ music-glossary
+ essay
+
+ notation blue 205
+ usage yellow 50
+ snippets
+
+ changes orange 30
+ extending red0
+ internals purple 280
+
+ contributor black doesn't matter - desat
+
+/**/
/* PAGE-WIDE SETTINGS*/
/**/
@@ -16,6 +40,15 @@ body {
background-color: #fff;
}
+/* Documentation-specific page-wide settings */
+
+body.learning{ background-color: #ccffcc; }
+body.notation{ background-color: #cceeff; }
+body.usage { background-color: #fff6cc; }
+body.extending { background-color: #ff; }
+body.internals { background-color: #eeccff; }
+body.contributor { background-color: #cc; }
+
/***/
/* HEADERS*/
/***/
@@ -24,7 +57,7 @@ body {
.appendix, .appendixsec, .appendixsubsec,
.unnumbered, .unnumberedsec, .unnumberedsubsec, .unnumberedsubsubsec,
.subheading, .subsubheading {
- color: #204a87;
+ color: #black;
border-bottom: 1px dashed black;
padding-bottom: 0.15em;
margin-top: 0.6em;
@@ -33,14 +66,22 @@ body {
.settitle {
background: #b1d281;
+ color: white;
font-size: 2em;
text-align: center;
padding: 0.4em 0
Re: Simplified version of Trevor Daniels' SATB framework. (issue 38720045)
On Wed, Dec 18, 2013 at 5:34 PM, wrote: > I'm not sure about using the default paper > margins. The printed output goes very close > to the left margin and the bottom of the bass > staff is cut off on some pages. Either LP's > defaults should be changed or we include the > values I suggested originally in my templates > in https://codereview.appspot.com/41990043/ . > > On balance I'd prefer to change them in the > template, on the grounds that they are tailored > for SATB layouts whereas the LP defaults may > be more suited to other forms of music. > I'm not sure I agree. I think for maximum utility, the template should define as little as possible regarding the physical dimensions of the page and margin, so that the user can use whatever style they want. For instance, I use a 1/4 inch margin on a half-letter format normally, but a 3/4 inch margin or so on a full letter size page. If the point is to simplify vocal scores, do the minimum required to produce the vocal score and leave the rest alone. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
On Wed, Dec 18, 2013 at 5:30 AM, Graham Percival wrote: > On Mon, Dec 16, 2013 at 01:50:53PM -0500, Carl Peterson wrote: >> (2) utilizing back-end scripting (PHP, etc.) to custom-serve the >> content based on the http header. > > We're using a donated web-server, and don't have root access. > When (not if) PHP has another security hole, I don't think we want > us to be responsible for somebody else's server getting hosed. > Indeed, I meant this paragraph to indicate two generally undesirable options for serving the content with the detected operating system info on top and all the other information rearranged on the same page, not as "this is what we should do." Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
On Mon, Dec 16, 2013 at 4:25 AM, David Kastrup wrote: > Carl Peterson writes: >> Just thinking out loud here...would it be worth looking into tweaking the >> .htaccess file to do OS-based redirection on the download page, like many >> sites do? That way, if someone requests download.html, they are redirected >> to download-win.html if the server detects Windows, download-mac.html if it >> dectects OS X, download-nix.html for *nix, and so on, with >> download-all.html being the current page (and .htaccess silently >> redirecting here if there is no OS match). This would allow us to put all >> the information on one page for an operating system and recommend or not >> based on what is actually available. > > No, based on what computer is used for downloading. That's more than > often sufficiently different to make this a nuisance. What we could > attempt doing is to move the entry for the purportedly detected > operating system to the top. Fair enough. That said, I'm not sure we can do this without either (1) introducing more redundancy in the individual documentation pages than Graham was concerned about (because then we still have to present the information on each page, just in a different order and layout), or (2) utilizing back-end scripting (PHP, etc.) to custom-serve the content based on the http header. It is interesting that in recent memory, almost every site I go to for downloadable software automatically serves the OS-specific version, including both commercial sites and open-source, etc. projects. Typically it would be something like: Download LilyPond [version number] for [operating system] (For other operating systems or versions, click here) [Present latest stable and dev versions side-by-side, with release notes and licenses linked in] [Insert note about LilyPond being text-based] [Link to OS-specific editing solutions] I'm not saying that this is necessarily the *best* solution, but I think the success rate seems to be high enough to warrant looking at. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
On Dec 16, 2013 12:16 AM, "Graham Percival" wrote: > > On Sun, Dec 15, 2013 at 01:23:51PM +0100, Urs Liska wrote: > > It was consensus that new users should actively be encouraged to > > download one of the complete environments, namely Frescobaldi or > > Denemo, which would then take care of installing LilyPond. > > Is Frescobaldi available on OSX? It's lacking the appropriate > symbol on the easier-editing page. > ... apparently it's only available in macports. That isn't > something that we should ask most users to try. > > Denemo is not available on FreeBSD or OSX (accoring to the > symbols) so we can't recommend it without deliberately ignoring > some users. Granted, anybody using freebsd will already know how > things work, but we shouldn't ignore OSX users, particularly since > many composers prefer OSX. > Just thinking out loud here...would it be worth looking into tweaking the .htaccess file to do OS-based redirection on the download page, like many sites do? That way, if someone requests download.html, they are redirected to download-win.html if the server detects Windows, download-mac.html if it dectects OS X, download-nix.html for *nix, and so on, with download-all.html being the current page (and .htaccess silently redirecting here if there is no OS match). This would allow us to put all the information on one page for an operating system and recommend or not based on what is actually available. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On Sun, Dec 15, 2013 at 2:40 PM, wrote: > Good point. The SA-TB template pair puts SA on one > staff and TB on another, but in this revision it has > only verses between. There is no reason why it should > not also have soprano lyrics above, bass lyrics below > and alto and tenor lyrics in-between, with each aligning > to their respective voices. I'll do that in the next > revision. I think then all the major SATB layouts will > be incorporated in just two template pairs. > > Trevor > > https://codereview.appspot.com/41990043/ There is that, and I realize after looking at the files again that you did address what I was asking about. But you do bring up a good point. Depending upon whether music is presented as through-composed or in songbook format (with verses), there may be a need for multiple sets of alternate (above or below staff) lyrics. I think I share in what I get to be the general sense of many of the comments that have been made thus far. There is a tradeoff between ease of default use and the customizability. To use a bad and probably over-generalized analogy, we're going from Linux (where you pretty much have to do it yourself, but you can make it do pretty much anything you want) to Mac (where everything is easy IF you are willing to work within the predefined templates, and anything else is almost impossible). We need something in between. I don't know that this is the route to go. If our goal is to get people using LP, I don't think that what we need is a function that hides basic structures from the users, where if they want to go beyond this, they have to move from two include commands to a whole new structure. I think what we need is a stripped-down choral/SATB layout that uses minimal overrides and extra code so that new users can copy-and-paste and start experimenting with. Cheers, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On Sun, Dec 15, 2013 at 4:51 AM, wrote: > > On 2013/12/14 23:17:55, Keith wrote: >> >> On 2013/12/14 22:32:06, Devon Schudy wrote: >> > This interface is unlike any other in Lilypond, > > >> This was intended not as an interface to a built-in bulletproof > > engine, but >> >> rather a template that users can adopt and change. > > > Exactly, although the flexibility greatly reduces the > need to 'adopt and change'. > > >> Maybe calling it a 'built-in' template, and its attempt to be as > > general as >> >> feasible, invites misunderstanding of its intended use. > > > Maybe. It's 'built-in' as there is no need to copy > and edit the templates, but perhaps a better word to > distinguish these templates from the previous ones > could be found. Suggestions welcome. > > Trevor > First question I anticipate from users on this, if we are making a canonical SATB score template in this way: How do I get the altos and sopranos on the same staff, and the tenors and basses on the same staff? For instance, this template doesn't help me at all, since I use the two staves instead of four. I could be wrong, and realize that many use separate staves, but there are also many who don't. Cheers, Carl P. https://codereview.appspot.com/41990043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Sat, Dec 14, 2013 at 1:50 AM, James wrote: > On 14/12/13 05:57, Carl Peterson wrote: >> I have updated the patch in Rietvald > > > But not the tracker. So the patch will not get tested. > > Please remember to either use git-cl or change the tracker to patch-new > whenever you make a change in Rietveld, we need to make sure that and new > patch doesn't break anything in current master no matter how innocuous you > think the changes are. > I am using git-cl. However, I think that there's an error message popping up saying that it can't edit the issue tracker. That may be since I'm not a project member on the Google Code site. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Fri, Dec 13, 2013 at 10:41 PM, Graham Percival wrote: > On Fri, Dec 13, 2013 at 10:02:23AM -0500, Carl Peterson wrote: >> On Thu, Dec 12, 2013 at 7:36 PM, wrote: >> > I think that the index sidebar colors are too dark. They dominate the >> > page, in my opinon. In the current design, the sidebar color and the >> > highlight box fill color are the same. Why not keep it that way? >> >> Attaching another option, to address your concern, as well as >> Graham's. > > Yes, much better! I have updated the patch in Rietvald (https://codereview.appspot.com/36480048/), per the images previously sent, with the exception that I slightly desaturated the colors to further reduce the "cartoonish" effect. Cheers, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 7:36 PM, wrote: > I think that the index sidebar colors are too dark. They dominate the > page, in my opinon. In the current design, the sidebar color and the > highlight box fill color are the same. Why not keep it that way? Attaching another option, to address your concern, as well as Graham's. The background is white, and the sidebar color is actually lighter than the currently-specified highlight box (in the code being reviewed), IIRC. Does this work better? Obviously, this isn't from the actual manuals, but is a mock-up just to see the color relationships. <>___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
On Fri, Dec 13, 2013 at 8:31 AM, James wrote: > On 13/12/13 13:04, Phil Holmes wrote: > > Thanks for what you're doing, but please don't put a lot of images on the > Google Issue tracker. For bizarre reasons only known to themselves, the > storage available for attachments is _very_ limited. By accident you've > just used about 1/25 of our remaining quota. > Sorry about that. I'll delete the comment once I've had a chance to make edits to the CSS file and produce new examples. > What I do when i test patches that have lots of reg test diffs to display is > use a service like this: > > https://www.hightail.com/ > I have ways of linking in images, and have done it on other things. I was just trying to keep everything self-contained within the available services. Now that I realize this is sub-optimal, I will pursue other ways of distributing the screenshots. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 1:06 AM, wrote: > > Message: > Patch for initial solution to issue 3714, regarding color-coding of > manuals. > > Please review this at https://codereview.appspot.com/36480048/ I have submitted follow-up patches to Rietveld to address comments regarding the duplicate CSS definitions. I also found where a change to simplify the manual-specific definition caused a problem with the "default" color choices (when a specific color set has not been defined), and have corrected this. For those who need a visual of these changes, I've uploaded screenshots to the Google Code issue. https://code.google.com/p/lilypond/issues/detail?id=3714. Regards, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 4:10 AM, wrote: > LGTM, although it is difficult to visualise > the effect of the various colours without seeing > them. > > https://codereview.appspot.com/36480048/ > I'll see what I can do about getting representative screenshots. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 7:49 AM, Carl Peterson wrote:
> On Thu, Dec 12, 2013 at 2:21 AM, wrote:
>
>> LGTM, with one small nit.
>>
>>
>> https://codereview.appspot.com/36480048/diff/1/
>> Documentation/css/lilypond-manuals.css
>> File Documentation/css/lilypond-manuals.css (right):
>>
>> https://codereview.appspot.com/36480048/diff/1/
>> Documentation/css/lilypond-manuals.css#newcode456
>> Documentation/css/lilypond-manuals.css:456: body.learning{
>> background-color: #ccffcc; }
>> This and the next lines are a duplication from the top of the patch.
>> Why? Looks like a mistake...
>>
>> https://codereview.appspot.com/36480048/
>>
>
> It could be. It may need to be deleted, or there may have been something
> else I was intending to style. I'll take a look a bit later today.
>
I just remembered. It does need to be deleted. I had pulled down the
earlier chunk of code to get the hex color values and forgot to take it
back out. I'll update the patch later, when I have access to my dev
machine. Thanks for catching.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 2:21 AM, wrote:
> LGTM, with one small nit.
>
>
> https://codereview.appspot.com/36480048/diff/1/Documentation/css/lilypond-
> manuals.css
> File Documentation/css/lilypond-manuals.css (right):
>
> https://codereview.appspot.com/36480048/diff/1/Documentation/css/lilypond-
> manuals.css#newcode456
> Documentation/css/lilypond-manuals.css:456: body.learning{
> background-color: #ccffcc; }
> This and the next lines are a duplication from the top of the patch.
> Why? Looks like a mistake...
>
> https://codereview.appspot.com/36480048/
>
It could be. It may need to be deleted, or there may have been something
else I was intending to style. I'll take a look a bit later today.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Dec 11, 2013 at 11:56 PM, Graham Percival wrote: > On Wed, Dec 11, 2013 at 11:26:55PM -0500, Carl Peterson wrote: > >In my searching, I didn't find a page that really did this. Section > 1.2 of > >the current CG should theoretically do this (based on the title), but > it > >mostly just talks philosophically about git. > > Sounds good. I've never liked that "wall of text" in CG 1.2. How > about you rename the existing section to something like > "Introduction to open-source development" or "Introduction to > git", then add a new section that's the kind of overview you > suggested. > > NB: this type of change is minimally invasive, has a well-defined > scope, and can be done in an hour without requiring lots of > discussion on -devel. By contrast, based on historical evidence, > any discussion about reorganizing any document is likely to > involve at least 5 hours of emails and has over a 50% chance of > somebody's feelings getting hurt. > > Once I have the current website/documentation patch through and the one that I need to redo properly (which was the original one that got me into the dev side), I'll start taking a look at this. The timing also has the advantage of letting me work through a couple of reviews myself to understand this end of the process better before I look at documentation that touches the process. Why can I never remember the old adage about suggestions? Never make a suggestion you aren't willing to implement. :) Oh, well. As they say, it builds character. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Dec 11, 2013 at 10:35 PM, Graham Percival
wrote
>
> Fixing this doesn't require a reorganization. It requires
> deleting the two incorrect bits, dumping a @ref{Submitting a
> patch} or whatever the @node is called. On a similar note,
> there's at least 2 "checklists before submitting a patch", at
> least 1 of which has obsolete info.
>
>
It may not "require" a reorganization, but is there a clearer, more concise
way of presenting the information to where there is "one truth" and we can
say, "if you want to contribute, go to this page for the process"? I think
there needs to be a page that just outlines the basic process and branches
based on what people are doing/using.
For instance, trying to synthesize the information in broad strokes (and I
could be missing, misstating, or overgeneralizing something):
1) You need to be running Linux.
1.1: If you aren't using Linux, you can run Linux within your current
operating system with LilyDev by following these instructions [link]
1.2: If you're already running Linux, great! Here's how to make sure you
have all the packages and tools needed to work on LilyPond [link]
2) You need to connect to the git repository and download the source files.
To understand what git is, go here [link].
2.1: If you are using the command line, go here [link]
2.2: If you are not comfortable using the command line, go here to
download lily-git.tcl [link]
3) Once you have downloaded the files, begin making your edits. Go here to
see some of our development policies and practices [link]
4) As you edit the code, you will need to make one or more local commits to
your code, to record your changes in a way that can be eventually
integrated into the official source.
4.1: If you are using the command line, go here [link]
4.2: If you are using lily-git.tcl, go here [link]
5) When you finish editing, you need to create patch files that represent
the changes you made
5.1: If you are using the command line, go here [link]
5.2: If you are using lily-git.tcl, go here [link]
6) With your patch files ready, go here for directions on how to upload
your changes for review and eventually submit them to the source code [link]
In my searching, I didn't find a page that really did this. Section 1.2 of
the current CG should theoretically do this (based on the title), but it
mostly just talks philosophically about git.
Cheers,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Dec 11, 2013 at 9:54 PM, Graham Percival wrote: > On Wed, Dec 11, 2013 at 01:48:54PM +0100, Janek Warchoł wrote: > > PS ccing to Graham because he might be interested to know that > > Someone(TM) is doing Something(TM) to help new contributors! > > Sorry, this awoke Grumpy Graham. > > Reorganizing the CG is very much a "something should be done, this > is something, so can somebody else do this thing". > > Is there any solid evidence that a serious contributor finds it > difficult to skip over section 2.1 if it's not relevant? > Speaking as the "new contributor" whose experience provoked Janek's indignation, here's my perception of things. Just to give my background, while I've not done much direct application (C++, etc.) programming, I spend most of my day in my "real job" looking at Microsoft Access databases and writing VBA code for those. In my spare time, whatever that is, and with some part time jobs, I do quite a bit of web programming, including writing a records management system in PHP. I'm familiar with version control, though until looking seriously at LilyPond, my VCS of choice was Subversion. To try to recount the process I went through awhile back, I did install LilyDev at first, when I was wanting to virtualize my dev environment on my iMac. Later, I brought out the Linux box I had set up with Debian a year ago and went through the process of updating it so that I could build LilyPond. I was able to connect to git with minimal fuss, and currently use the lily-git.tcl tool to handle commits and patches. All that said, where things got interesting for me was when I wanted to figure out how to submit my patch. Following through the directions in 2.2 (lily-git), I got to this text: > Send patch files to the appropriate place: > > * If you have a mentor, send it to them via email. > * New contributors should send the patch attached to an email to fr...@lilynet.net. Please add “[PATCH]” to the subject line. > * Translators should send patches to translati...@lilynet.net. > * More experienced contributors should upload the patch for web-based review. This requires additional software and use of the command-line; see Uploading a patch for review. At first, I sent the patch to Janek, because the area I was working on (Metafont) was an area he had done some work in and while he doesn't claim to be an expert, I felt that he was someone worth going to, more or less a "mentor" (and yes, I realize that word and the relationship is defined more concretely elsewhere, but at this point, I don't really see any "mentoring" going on, which begs the question of whether it should even be mentioned). After taking a look at the patch, he let me know that I really needed to submit the patch myself. So I went to the second option, since I think I meet the definition of "new contributor." I told Janek that and copied in the text above in an email, which precipitated what most of you all have seen. I don't know that the organization of the CG is *necessarily* wrong (except where processes are obsolete for various reasons), but I think that instead of providing one concrete workflow for contributing, there are a lot of options offered and described in more or less detail in different places, which can be confusing for anyone who isn't an "experienced developer" (in the sense of being familiar with git and other such tools). I felt like I was going around in circles and never able to find the same information the same way across multiple times trying to look the information up. Cheers, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon wrote: > > The only hassle for me, which I did not run up against when I started with > the project, is David’s way of communicating. I’m not claiming this is all > on him, but I’m also pretty sure that I’m not the only one who has peaced > out because of this. I am looking for ways for this to no longer be an > issue. I was hoping that branches would go a way towards making this > happen for myself and hopefully other developers, but it’s clear that this > is not a good idea. > > In my two day jobs, director of the ensemble 101 and developer for the > Guido project, I work with two (very different) teams of people on projects > that require creativity, consistency, and tons of communication. Neither > of them has any of this friction resulting from communication issues, both > of them enjoy a diversity in major contributions, and both are evolving > rapidly and stably in several interesting ways at the same time. I truly > hope that LilyPond can be like that. > > I don't know how you communicate with your other two teams, but the simple fact is that email is a terrible method of communication, when it comes to the things that you appear to be seeking. An amused or straightforward comment can across as harsh or sarcastic when visual and aural cues are absent (citing the studies that show that 90% of communication is nonverbal, i.e., not connected to the actual words). Some people's manners of speech translate into text-only communication better than others', and some don't translate at all. I had a boss a couple of years back who could be very friendly and personable face-to-face, but unless she was obvious happy about something, always came across as stern and upset with the way things were done. It happens. But you may already be well aware of all this. It is regrettable that you would let such things interfere with your contributions to LilyPond. Ultimately, it is about the project, not the people. Perhaps counter-intuitively, the answer to the problem you perceive is not to reduce participation, but to increase participation. In my own case, my interactions with David had the effect of getting me more involved in the "behind the scenes" workings of the code. Why? So that eventually, David won't be able to criticize me for not being willing to "get my hands dirty." I haven't made a commit yet, but that's probably a matter of weeks or days (whenever I get git-cl set up on my dev machine). In the meantime, instead of complaining about this feature or that feature, or going "Oh, poor, pitiful me, someone give me a code snippet to do x," I've tried to dig into things to make them work. Now the thing I'm trying to figure out is how to make what I'm doing usable for others who do the same things so that LilyPond is an easier environment to use. Will I ever get to where I'm wrangling the underlying C++ code? Probably not. But I'm working on what I can. Cheers, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
