Re: How to increase the distance between the last note of a measure and the following bar line

[Paolo Prete]

(En passant: I tried \info BarLine but could not see "extra-spacing-width". See the attached debug)

But in general, I think it's not a good idea to dump these kind of doc infos as the output of a library, for several reasons.

First of all because it has limitations in formatting and in linking between different pages. The resulting output is therefore too long to read.

I think it's enough to make some adjustments to the current output of the autodoc tool.

First one would be to add, with small fonts, at the bottom of the page, a list of the pairs (as links): class/interface - overriden/implemented property, inside an expandible panel (hidden by default). 

In this way, IF I can't find an useful property in the main panel, THEN I can look at the implemented interfaces list at the bottom. At this point, if in this (short) list there's a name that looks interesting, I click on it without expanding the below panel, and I jump to the linked page. If I can't guess the right interface, I would expand the below panel and I would look more accurately in the contained (long) list. This avoids to jump forth and back from page to page.

In general, I see this as a good default choice for the autodoc of libraries, but even if it's not set as default, the command to produce a complete autodoc should be documented as well. In this library (which I made some years  ago and could not update, in the last years)

https://github.com/paolo-pr/laav

you can find a directory for the autodoc (Doxygen) and the instructions to build it. Then, it is left to the user how much complete or minimal the autodoc has to be.

Best, 

P

On Wed, Nov 10, 2021 at 10:36 PM Jean Abou Samra <jean@abou-samra.fr> wrote:

[Kieren]
>> The page in the Internals Reference doesn't
>> list all the properties that the grob would
>> support, only those for which it has a specific
>> default. You have to explore the interfaces to
>> find other interesting properties that you can
>> tweak. In this case, click "Item" ("This object
>> is of class Item"). You'll find extra-spacing-width
>> in the item-interface.
> This is something I’ve asked a couple times before, but been dismissed… Maybe you can help?
>
> Is there an Automagic™ way to print out a “complete tree” of all properties that a grob supports, including any default values?


Sure. How about the attached?

Bear in mind that this may stop working in future
versions (in fact I have a branch somewhere that
would definitely break it if I ever manage to
complete the work).


[Paolo]
> Thanks.
>
> However, when looking for a property or function that might fit what I
> need, I always check for inherited stuff. In this case, unfortunately,
> the search is a bit cumbersome and tricky and it's not the first time,
> especially when the properties are so many and I have to write the
> code quickly, that I don't find the right property.
> Suppose that an object has many settable properties: there is a main
> page of this object, let's call it "A", and other pages with inherited
> properties (B, C, D, E etc.)
> When I do a search, I first look inside A: if I don't find anything
> useful, I look in B and if I don't find anything useful here too, I go
> back to A and then I go to C etc.
> You can understand that, when there are so many properties, jumping
> back and forth from page to page is inconvenient to remember what is
> available as a sum of things. In many automatic documentation of other
> libraries I use, the inherited properties and functions are listed
> grouped (with relative links), sometimes in small format, at the
> bottom of the page to avoid this inconvenience.
> It is true that the resulting page is longer, but it is not heavier to
> read. Furthermore, in this way you can read only the names, without
> the descriptions, of these properties and this allows you to decide
> whether or not to jump to the page that defines the inherited property
> to try. Mine is a suggestion, and I think it's useful to add it to the
> documentation (or at least explain how to create this "extra"
> documentation automatically)


Would the attached mock a good way to format
this documentation in your opinion?

Best,
Jean

debug.txt
Description: Text document