help-gnu-music
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two notes sharing a head


From: Mats Bengtsson
Subject: Re: Two notes sharing a head
Date: Mon, 13 Nov 2000 22:39:48 +0100

> address@hidden writes:
> > > 
> > > It's still in flux, and we appreciate comments about how we can make
> > > it easier to navigate.
> > 
> > For this particular example, you won't find the answer clicking on 
> > Collision_engraver. Try to click on note-column-interface.
> > Why isn't this information included in the documentation of
> > NoteColumn?
> 
> Because listing unset properties generates huge pages that all look
> alike.  I think it is better to have most information in screen-sized
> chunks.

OK, it wasn't obvious to me that the properties listed for
each element were only those explicitly set, not all available
in the interfaces.

> > The table of contents looks really weird for the
> > contexts. A search facility and back-links from interfaces 
> > to elements would make it slightly more easy to navigate,
> > but you still more or less have to now the answer to be able
> > to find the documentation. 
> 
> I added links leading from ElementName to all the interfaces it
> supports.  I especially added a link from note-collision-interface to
> note-column-interface (modulo typing error), and a link  back.  I don't
> really understand why you think the information is hard to find.

That's much better. Now it's actually possible to find the 
property merge-differently-dotted by clicking on something
named collision and then following the links. In the earlier
version, it was very hard to find without an extensive search.

> > (I still don't understand why the different interfaces have to 
> > be visible in the user documentation.)
> 
> Why do the different interfacess have to be invisible in the user
> documentation?

Of course they should be visible if they bring some 
relevant or enlightning information. Now with your
answer to the first question above, I realize that they
may be useful as "section headers" for a group of 
related properties. Still, I don't see that they are
essential entities in the user interface of Lilypond, 
just an implementation structure.


    /Mats





reply via email to

[Prev in Thread] Current Thread [Next in Thread]