lilypond-manuals.css: Add a maximum width for manuals sidebar (issue 328740043 by paulwmor...@gmail.com)

[paulwmorris]

Reviewers: ,

Message:
Please review, a few follow-ups to the previous manuals css patch.

The following demo site reflects the changes in this patch (remove
spaces after the domain).

http://clairnote.org   /lilypond-web-demo/Documentation/

(I'll upload a screenshot showing the former brown color on the issue
tracker.)

Thanks,
-Paul

Description:
lilypond-manuals.css: Add a maximum width for manuals sidebar

When the browser window is 1280px wide or more, the sidebar
will be 346px wide, rather than a percentage of the window
width.

Also contains these two commits:

lilypond-manuals.css: A better brown for the usage manual

I think this shade goes better with the other colors,
giving us a more coherent color scheme across manuals.

lilypond-manuals.css: Add space between top-levels in sidebar

(This one was originally in my last patch for the manuals css,
but I found a better way to do it, so removed it from the
previous patch and including it here.)

Please review this at https://codereview.appspot.com/328740043/

Affected files (+19, -1 lines):
  M Documentation/css/lilypond-manuals.css


Index: Documentation/css/lilypond-manuals.css
diff --git a/Documentation/css/lilypond-manuals.css  
b/Documentation/css/lilypond-manuals.css
index  
d444792955d54edb875b65b5f6b153716863174e..f7b88a1ca27e495bb5d9f640f8109baa15b1d73b  
100644

--- a/Documentation/css/lilypond-manuals.css
+++ b/Documentation/css/lilypond-manuals.css
@@ -257,7 +257,7 @@ div#tocframe {

 body.learning#tocframe { background-color: #407f40; }
 body.notation#tocframe { background-color: #40657f; }
-body.usage   #tocframe { background-color: #7d765a; }
+body.usage   #tocframe { background-color: #81613e; }
 body.extending   #tocframe { background-color: #7f4040; }
 body.internals   #tocframe { background-color: #6a407f; }
 body.contributor #tocframe { background-color: #33; }
@@ -323,6 +323,10 @@ div#tocframe h4 {
   font-size: 1em;
 }

+#tocframe .contents > ul.toc > li {
+  margin-top: 0.5em;
+}
+
 #tocframe ul.toc li li {
   padding-left: 1em;
 }
@@ -495,3 +499,17 @@ div#search p, div#search form {
   border-radius: 5px;
   margin: 0.5em 0.5em 2em 3em;
 }
+
+/***/
+/*   RESPONSIVE DESIGN */
+/***/
+
+@media (min-width: 1280px) {
+  div#main {
+left: 346px
+  }
+  div#tocframe {
+width: 346px;
+right: 0;
+  }
+}



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [patch] Add a work to "we wrote" list

[Francisco Vila]

I would like to push this patch if nobody explicitly opposses.


El 15/04/17 a las 13:03, Francisco Vila escribió:
> Thanks James for waiting for me to get home.
>
> 2017-04-07 16:56 GMT+02:00 Han-Wen Nienhuys :
>> This links to https://cloud.paconet.org/tesis/tesis.pdf, which is 404.
>> I think you mean https://paconet.org/tesis/tesis.pdf ?
> This is the deep link but I'd rather link to a wiki page containing
> some meta info. From here,
>
>   https://paconet.org/wiki/index.php?title=Tesis
>
> (note the https) links correctly to the wiki a 200 OK result, whereas
>
>   http://paconet.org/wiki/index.php?title=Tesis
>
> (note the http) gives 301, then 404, but on a browser it redirects to
> the https, furthermore:
>
>   https://www.paconet.org/wiki/index.php?title=Tesis
>
> (note the www) gives problems with my cheesy, temporary certificate
> config, but this is not the link I posted, and
>
>   http://www.paconet.org/wiki/index.php?title=Tesis
>
> (note the http and www) also gives 301, then 404 and on a browser it
> also redirects to the https and www and therefore to the problem.
>
> In short, if the original link does work I'd like to maintain it. If
> not, the deep link is suboptimal but also acceptable.
>
> Thanks for your time.
>
>
>


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: engraver to change staff name based on visibility of related staff?

[Thomas Morley]

2017-06-16 23:47 GMT+02:00 Shevek :
> Following up on an aspect of the discussion on parts sharing a staff
> (http://lilypond.1069038.n5.nabble.com/parts-sharing-a-staff-tt203873.html).
>
> I've spent quite a few hours over the last day trying to figure out how
> engravers work and how I might take a crack at writing something to
> automatically handle changing Staff names for divisi staves. I feel like
> I've understood most of what I've read, but I'm still totally befuddled.
> This seems like a difficult problem because:
>
> 1) It's completely opaque to me how one would check if a Staff is visible or
> not on a given system. The hara-kiri-group-spanner, as far as I can tell,
> does its work without telling anybody about it. There's not like a boolean
> function you can call to find out if a context will be visible.
>
> 2) One needs to do something in one context depending on what happens in a
> different context. Most of the example engravers just do something in one
> context. Keep_alive_together_engraver collects grobs from different contexts
> and tells them about each other, but then relies on on them to figure out
> what to do with that information. That doesn't seem adequate here.
>
> 3) Such an engraver would need to step through the score by system, after
> breaking, rather than event by event, and it might need to be able to
> backtrack to insert an event to change the instrument name prior to the most
> recent system break. The code and documentation I've read has not given me
> any insight into how one might do such a thing.
>
> I'd love some feedback and guidance.



Hi,

I doubt an engraver will ever work for this purpose. As far as I
understand an engraver usually puts in stuff far too early. You can
assign a procedure to a grob via 'after-line-breaking, but you will
not be able to access whatever the procedure returns _in_ the
engraver.
I may be proven wrong, though.

Nevertheless, I tried a different approach:

\version "2.19.62"

%% NB
%% It's a proof of concept, nothing more!!
%% Currently it will fail for various reasons with extended examples
#(define change-instr-names
  (lambda (grob)
(let* ((sys (ly:grob-system grob))
   (sys-all-elts (ly:grob-object sys 'all-elements))
   (sys-all-elts-list
 (if (ly:grob-array? sys-all-elts)
 (ly:grob-array->list sys-all-elts)
 '()))
   ;; get all VerticalAxisGroup-grobs per System
   (vertical-axis-group-list
 (filter
   (lambda (g)
 (grob::has-interface g 'hara-kiri-group-spanner-interface))
   sys-all-elts-list))
   ;; get all InstrumentName-grobs per System
   (instrument-names-list
 (filter
   (lambda (g)
 (grob::has-interface g 'system-start-text-interface))
   sys-all-elts-list))
   ;; construct a nested list like
   ;;   ((#t #)
   ;;(#f #))
   ;; the boolean indicates whether the Staff is alive, derived from
   ;; VerticalAxisGroup.Y-extent
   (alive?-instr-list
 (map
   (lambda (v i)
 (list (interval-sane? (ly:grob-property v 'Y-extent)) i))
   vertical-axis-group-list
   instrument-names-list)))

   ;(pretty-print alive?-instr-list)

  ;; First constructing a list and then fragmenting it in various ways is
  ;; not elegant, to say the least.
  ;; Just a proof of concept...
  (if (any not (map car alive?-instr-list))
  (let* ((instr-to-set
   (remove
 (lambda (e)
   (not (car e)))
 alive?-instr-list)))
(ly:grob-set-property! (cadar instr-to-set) 'text
  (make-column-markup
(map
  (lambda (arg)
(ly:grob-property arg 'text))
  (map cadr alive?-instr-list)


%% Example


\layout {
  \context {
  \Staff
  \override VerticalAxisGroup.after-line-breaking = #change-instr-names
\RemoveEmptyStaves
  }
}

<<
  \new Staff \with { instrumentName = "One" shortInstrumentName = "one" }
{ R1 \break c \break c }
  \new Staff \with { instrumentName = "Two" shortInstrumentName = "two" }
{ c1 R c }
>>


Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

engraver to change staff name based on visibility of related staff?

[Shevek]

Following up on an aspect of the discussion on parts sharing a staff
(http://lilypond.1069038.n5.nabble.com/parts-sharing-a-staff-tt203873.html).

I've spent quite a few hours over the last day trying to figure out how
engravers work and how I might take a crack at writing something to
automatically handle changing Staff names for divisi staves. I feel like
I've understood most of what I've read, but I'm still totally befuddled.
This seems like a difficult problem because:

1) It's completely opaque to me how one would check if a Staff is visible or
not on a given system. The hara-kiri-group-spanner, as far as I can tell,
does its work without telling anybody about it. There's not like a boolean
function you can call to find out if a context will be visible.

2) One needs to do something in one context depending on what happens in a
different context. Most of the example engravers just do something in one
context. Keep_alive_together_engraver collects grobs from different contexts
and tells them about each other, but then relies on on them to figure out
what to do with that information. That doesn't seem adequate here.

3) Such an engraver would need to step through the score by system, after
breaking, rather than event by event, and it might need to be able to
backtrack to insert an event to change the instrument name prior to the most
recent system break. The code and documentation I've read has not given me
any insight into how one might do such a thing.

I'd love some feedback and guidance.



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/engraver-to-change-staff-name-based-on-visibility-of-related-staff-tp203905.html
Sent from the Dev mailing list archive at Nabble.com.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Various chain-assoc-get -> #:properties (issue 323940043 by d...@gnu.org)

[dak]

https://codereview.appspot.com/323940043/diff/20001/Documentation/snippets/new/three-sided-box.ly
File Documentation/snippets/new/three-sided-box.ly (right):

https://codereview.appspot.com/323940043/diff/20001/Documentation/snippets/new/three-sided-box.ly#newcode36
Documentation/snippets/new/three-sided-box.ly:36: (let* ((pad (*
(magstep font-size) box-padding))
On 2017/06/16 21:59:49, Carl wrote:

Looks like this could now be a let instead of let*


Done.  Not going to create a new review for it though.

https://codereview.appspot.com/323940043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel