Summary of markup-related ideas

[mike]

Plan for revising markups ::

NAMESPACE MANGLING OF GROB PROPERTIES

--) function

All grob properties will be associated with their interface.  So, `Y-extent' 
will no longer be internally represented as `Y-extent' but rather 
address@hidden'.  When someone does:

\override Stem #'Y-extent = #'(0 . 0)

or

(ly:grob-property stem 'Y-extent)

or

(ly:grob-set-property! stem 'Y-extent '(0 . 0))

LilyPond will automatically mangle the property to the right name by searching 
all of the grob's interfaces and attaching the correct one.

If the user writes in the mangling, like:

\override Stem #'address@hidden = #'(0 . 0)

LilyPond will be smart enough not to do the automatic mangling.

--) rationale

Eventually, in the model elaborated below, advanced users will be creating 
their own grobs on the fly with custom properties and interfaces.  Most of 
these definitions will need to be basic, on the order of:

#(define-markup-command (foo layout props bottom top)
  ...)

#(define-markup-command (bar layout props bottom top)
  ...)

LilyPond will do some magic (through functions...ideally not through macros) to 
create the "Foo" grob with properties address@hidden and address@hidden that 
implements markup-interface and foo-markup-interface.  Ditto for the Bar grob. 
This type of namespace mangling assures that no properties are double-defined.  
It is a sort of namespacing of properties.

REWRITE OF define-markup-command

--) function

All markup commands should do either two things.

1) The creation of a Grob.
2) The overriding of a Grob.

So:

\markup "foo"

Will create a `MarkupText' grob that has as its #'text property "foo"

\markup \raise #0.5 \note #"4" #UP

Will create a `NoteColumn' grob that has its Y-offset property chained to a 
callback that raises it by 0.5.

\markup \column { foo bar }

Will create a `Container' grob that has in its element list two MarkupText 
grobs and a layout-manager property of column-layout-manager (see below).

\markup \concat { foo bar }

Will create a `Container' grob that has in its element list two MarkupText 
grobs and a layout-manager property of concat-layout-manager.

Somehow, define-markup-command will have to do the on-the-fly creation of grob 
definitions if they don't already exist and create the corresponding grobs.

--) rationale

Currently, all markups are evaluated @ compile time save certain esoteric 
situations.  This means that they cannot communicate with scores at all.  It 
makes their layout possibilities rather limited and requires kludgy functions 
to deal with retrieving page numbers and footnotes for markups.  If every 
graphical object in LilyPond has the internal representation of a grob, it'll 
make handling them much more uniform and extensible.

CREATION OF THE LayoutManager CLASS

--) function

SpacingSpanner, Page_layout_manager, and other things that take care of the 
positioning of other grobs will inherit fro the layout manager class.  In 
theory, any layout manager should be able to take a group of grobs and lay them 
out according to their rules (i.e. Java).

--) rationale

Currently, there are a lot of aspects of LilyPond with shared functionality 
(i.e. \justify in markup-speak and the SpacingSpanner) that are not grouped 
together in class inheritance mechanisms.  By doing this, we'll provide an 
easier template for future development.

ELIMINATION OF THE Prob CLASS

--) function

Everything is a grob.  A System is a grob that can be split up into several 
systems and put into a Container grob with a MarkupText.
A Page is a spanner that is split into several broken_intos_ on which various 
other grobs are put.
A Book is an object that contains several pages in a given orientation 
(vertical, horizontal, etc.).

--) rationale

With this addition, a cross-staff Beam can theoretically connect beams from two 
different scores on the same Page (or even the same Book) because there will 
always be a common-Y.

EXTENSIBILITY

--) function

LayoutManagers and grobs should be easy to define on the fly through various 
channels.  define-markup-command should, in theory, be able to define both 
(depending on what the markup command does).

--) rationale

This is in keeping with developments in LilyPond like Scheme engravers.

*****

That's a lot of text!  But, it may be worth it to go down this road now.  At 
the coding partaaayyyy, Nicolas Sceaux told me that the idea was kicked around 
before I was born to do some serious overhaul on markups, but it was then 
decided that this was more trouble than it was worth, so markups kinda stay put 
in their conceptual advancement while grobs took many great leaps forward.  
It'd be great to get markups to this level of sophistication as well, mostly so 
I could typeset the contemporary music example on the SCORE webpage using 
LilyPond.

Cheers,
MS