In response to Elaine and Urs 1) I already thought about the way to automatically feedback the modifications to the original .ly file, instead of the alert() string.
Again, it will be 100% JS + SVG. Just have a little patience ;-) Basically, Lilypond will have to import the original .ly code as the value of some property of a dummy node <g> at the end of the <svg> tree, in the way Aaron made for the previous snippet. Then with JS I can modify the content of this big string, and save back a modified file https://stackoverflow.com/questions/23218174/how-do-i-save-export-an-svg-file-after-creating-an-svg-with-d3-js-ie-safari-an 2) About linking an external js script, instead of the whole content of the code: you can already do that, just follow the answer of Aaron to my question: https://lists.gnu.org/archive/html/lilypond-user/2019-12/msg00251.html However, this approach is useless for now. The code is not mature for providing an external lib. I still have to define the general template for this feature (as you see, there are fixed functions: initGrob(), selectGrob(), moveGrob()... ) I suggest to test at least three snippets for different properties (I just created the second one). All the rest will follow as a natural consequence. Best, P On Tue, Dec 17, 2019 at 3:05 AM Flaming Hakama by Elaine < ela...@flaminghakama.com> wrote: > ---------- Forwarded message ---------- > > From: Urs Liska <li...@openlilylib.org> > > To: lilypond-devel@gnu.org > > Date: Mon, 16 Dec 2019 10:18:36 +0100 > > Subject: Re: A snippet for editing curves using the mouse and reporting > > changes to the .ly file > > Hi Paolo, > > > > I have followed the discussion but didn't have the time to actually test > > your code until today. > > > > First of all let me state that this is really great, and when I will > > raise some issue these are in no way meant as critique. I really want to > > see this integrated in the toolbox in one way or another, but there are > > a few minor and major questions that should be answered before. > > > > Regarding integration in Frescobaldi I agree that it's appropriate to > > create an independent version of the code and then have Frescobaldi deal > > with it. > > > > Generally I'd say this functionality should be integrated in LilyPond > > itself, and I hope we'll find a version that satisfies all potential > > questions. > > What Werner Lemberg hinted at when mentioning my name was that we could > > alternatively or additionally include the snippet in the openLilyLib > > package oll-misc (https://github.com/openlilylib/oll-misc/). While I > > prefer having it in LilyPond proper you should understand that any > > addition we do now will most surely *not* be included in the next stable > > release 2.20 but will only be available through the next development > > version. Judging from recent history version 2.22 may be quite some way > > in the future. > > For me this won't be an issue since I'm always using the development > > version, but if we want this functionality to be generally available we > > might better include it in LilyPond itself and then *additionally* to > > openLilyLib. > > > > Now to the functionality itself. Again, the length of the list of > > comments should not diminish my excitement about your code! > > > > * For integration in LilyPond the functionality should be wrapped into > > a single file that can be included. Including the file should > > automatically activate the functionality. > > Maybe there should be a second includable file that does *not* > > automatically activate the functionality but provides a command to > > selectively switch it on and off or apply it to only one curve. > > There may be people who don't want the whole score to be polluted > > with the control points but only see the slur they want to edit. > > * The behavior of the script in the SVG file is too intrusive IMHO. > > o forcing the interface with the pop-up prevents any external > > contexts (like e.g. Frescobaldi) from accessing the > > functionality in the way they need to. There should be some way > > to interact with the data in a different way. Also, it should be > > possible to get to the raw data instead of the formatted \shape > > command string. > > o It seems the function prevents point-and-click from working. I > > assume this is related to your decision to “hijack” the context > > menu functionality. > > o If that's correct (or even if not) I think the context menu > > should not be blocked in this way. Probably it's a better > > approach to *add* an entry. Maybe this is also a usable hook for > > external programs to integrate your function. > > * There is one flaw in the behaviour: When you include the generated > > \shape command in the score and recompile the modified slur is drawn > > correctly (which is totally great!). However, when you now modify > > that slur again (which is a very reasonable expectation) the \shape > > command is now calculated relatively to the already-applied \shape, > > so *now* the recompilation will produce a totally unexpected result. > > I see two possible solutions: > > o Somehow determine if a \shape has already been applied to the > > slur and consider the values when generating a new \shape. I > > have no idea whether this is possible. > > o Don't use \shape at all but finally integrate \shapeII into > > LilyPond and use it for the graphical tweaking. With \shapeII it > > is possible to much more robustly shape a slur than with \shape, > > and it is somewhat more absolute. I've attached the > > documentation PDF, and you can find the code at > > > > > https://github.com/openlilylib/snippets/tree/master/notation-snippets/shaping-bezier-curves/shapeII > > (don't let the warnings scare you when compiling the example > file). > > There would be some figuring out how to best apply the function, > > starting from the approach of polar coordinates, I'd say. > > To make it work, the function would have to do some more > > calculations that simply measuring the offsets, but I'm > > convinced it would be more than worth the effort. > > > > Best > > Urs > > > > Am 16.12.19 um 03:42 schrieb Paolo Prete: > > > Hello, > > > > > > the snippet attached to this mail allows the tuning with the mouse of > the > > > curves generated by Lilypond so that the changes can be reflected on > the > > > original .ly file. > > > The tuning is done on the generated SVG file, as explained in this > thread > > > (but you can look at the code of the attached file, there's a mini > how-to > > > and it's very simple to use): > > > > > > https://lists.gnu.org/archive/html/lilypond-user/2019-12/msg00217.html > > > > > > Since the snippet is incompatible with Lilypond 2.18 it cannot be > > included > > > in the snippets repository of that version, as explained by Thomas (it > > > would be bad to downgrade the code). > > > Is it possible to include it in the development version, then? > > > > > > (I also ask Aaron to revise the indentation / length of lines of the > > Scheme > > > code) > > > The snippet has had very positive feedbacks, and should not be left > > without > > > a future, IMHO. I believe it can define a template for the tuning of > many > > > other properties of graphic objects, in a very simple way both for the > > > Lilypond user and for those who want to extend the procedure through > > > Javascript. > > > > > > In the Lilypond user ml they suggested to include it in Frescobaldi or > > > Denemo; but I don't think it's the best solution. Because, being the > > > snippet 100% lilypond native code, it does not need any additional tool > > to > > > work, and demonstrates the potential of Lilypond in generating > > interactive > > > SVG. To be more precise, given that it is 100% Lilypond, Frescobaldi > and > > > Denemo should recognize it automatically. > > > It is also true, as Carl states, that LilyPond is not intended to be a > > > WYSIWYG software; but I believe that the "tuning" through GUI is not > > > opposed to this vision but integrates it, especially considering that > the > > > GUI is generated by Lilypond itself. > > > > > > Best, > > > Paolo > > > > Like Urs, I hope my comments are not taken as any kind of criticism. > This is amazing work, and I'm just hoping to contribute to making it > better. > > > > While the approach of including the JavaScript as CDATA has been shown to > work, I wonder if that is the best way to do it. The main issue being, you > can't just write any old JavaScript, since it is nested within a double > quote, so you have to avoid use of double quotes (or escape them). > > Even within this current approach, I'd prefer to see the JavaScript code in > a separate .js file, and included via \include. That would make it clearer > that the code is in fact JavaScript, and let anyone who might want to edit > it take advantage of syntax highlighting. > > > But the CDATA approach seems like a non-ideal way to link things together. > Especialy since SVG lets you include JavaScript by referencing an external > file, why not just publish the JavaScript in a file, then reference that > file from the SVG? > > Ideally, if this were to be the beginnings of a framework to allow > scripting in SVG files, we could have a command line argument that > specifies a script location, and it would add that reference in the SVG. > (For this particular feature, perhaps the feature's flag would know the > default JavaScript file and include that.) > > > > Regarding the behavior of the script in the browser, I agree that there > could be other ways of delivering the Shape data. I'm not sure that pure > SVG will allow these, so we might have to use an HTML document that > includes the SVG, as well as other elements. Which would also allow > multiple SVGs to be edited in the same document. > > I'm not sure what the issue is with pop-ups that Urs mentioned. > Philosophically, I agree that overriding the right-click default menu is > not ideal. But I'm not sure quite why it is a dealbreaker in terms of > integration with other apps like Frescobaldi. > > Here are some alternative ideas. > > Assuming we leave the right-click behavior, the popup could include a > button that says "Save", and clicking it could append the Shape > modification text to some other element on the page, or log it to the > console, or save it to a data object or to local storage. For the > data-based versions, there could be another button, perhaps located in a > control panel in the header, footer, left or right column, or in a popup, > that could display the mods in another element and/or copy to clipboard. > > If we don't like the right-click behavior, this same idea of presenting a > "save" button could be added to the initial drag behavior, eliminating the > need to right-click and override the default menu. Or, the button could be > located in the control panel, and would be aware of what the currently > selected shape is. > > > The other main feature that would make this absolutely killer would be to > have a way to connect the mods with the source code. Seems like the > weakest point of the current workflow is identifying the place in the > source code which shape is being modified, then manually cutting/pasting. > > In my mind, the ideal approach would be for every shape to have an ID, and > then the shape mod could reference the ID. Then you could just load your > mods in one place (either inline, or in an included file.) > > I suspect that the closest thing we have is the OLL, which allows you to > specify mods based on timestamp. > > I understand that a pure lilypond solution is ideal, and therefore using > OLL is not ideal, But, OLL does already exist as a framework for exactly > these kind of separate-presentation-from-content issues, so it seems worth > exploring. > > So, the question becomes, is it possible to include in the SVG elements the > timestamp? If so, then it would be possible to format the Shape mod as an > OLL directive, where we read the timestamp address from an attribute. > > The workflow would become: 1) Run the SVG (or HTML) document in the > browser. 2) Edit shapes, and for each one you like and want to apply, click > the "save" button. (maybe we also need a "delete mod" button by each entry, > in case you change your mind) 3) When you are done editing shapes, click > a "show all mods" button that displays the mod text in an element or popup. > 4) Copy the list of mods from the element and paste them into your OLL > overrides file. > > > If any of these UI suggestions are welcome, I can work on the JavaScript > side of it. > > > > Regarding re-indenting the scheme code, here is my attempt: > > \version "2.19.45" > > % lily-easy-slurs.ily > > showControlPoints = #(grob-transformer 'stencil > (lambda (grob orig) > (define (draw-control-point pt) > #{ \markup \translate $pt \with-color #red \draw-circle #0.35 > #0 ##t #} > ) > (define (draw-control-segment pt1 pt2) > (let > ((delta > (cons > (- (car pt2) (car pt1) ) > (- (cdr pt2) (cdr pt1) ) > ) > )) > #{ \markup \translate $pt1 \with-color #'(1 .5 0) > \draw-line $delta #} > ) > ) > (let* > ( > (pts (ly:grob-property grob 'control-points)) > (dots > (map > (lambda (pt) (grob-interpret-markup grob > (draw-control-point pt))) > pts > ) > ) > (lines > (map > (lambda (pt1 pt2) (grob-interpret-markup grob > (draw-control-segment pt1 pt2)) > ) > pts > (cdr pts) > ) > ) > ) > (ly:stencil-add > (apply ly:stencil-add lines) > (apply ly:stencil-add dots) > orig) > ) > ) > ) > > \layout { > \context { > \Voice > \override PhrasingSlur.stencil = #showControlPoints > \override PhrasingSlur.output-attributes = #'((class . > "lilySlur")(slurtype . "PhrasingSlur")) > \override Slur.stencil = #showControlPoints > \override Slur.output-attributes = #'((class . "lilySlur")(slurtype > . "Slur")) > \override Tie.stencil = #showControlPoints > \override Tie.output-attributes = #'((class . "lilySlur")(slurtype > . "Tie")) > } > } > > > HTH, > > Elaine Alt > 415 . 341 .4954 "*Confusion is > highly underrated*" > ela...@flaminghakama.com > Producer ~ Composer ~ Instrumentalist ~ Educator > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >
