This is an attempt at solving several problems reported by novice
users. The old rendering was very compact and quite fine once you
got used to its, ..., "conventions". But it was also sometime rather
hard to read.
First of all, it abused bold and italic. It also "merged" optional
parameters and parameters with default content. It got worst when
the documentation was spread over mutiple lines.
For property types and constructors with large number of parameters,
it was also quite unreadable.
The new representation, while far from perfect, is less dense and
more explicit. It has a separate column for "optional" using the
new "metadata chip" documentation concept. It is also an aligned
table and correctly renders multi-line documentation.
Finally, it adds a "note" message when the named parameter convention
is used. This way the users looking at the examples will be less
confused.
Below a screen width of 768px (Bootstrap's "medium" breakpoint)
the sidebar will collapse to a small strip. Hovering the sidebar will
fully reveal it until the mouse leaves it.
Clicking the sidebar will reveal it until another part of the page is
clicked.
It is hard know to which row a "chip" like inherited belongs to. This
fixes it for mouse users.
I also tried using alternate row colors, but our colors are so "light"
that there wasn't any good candidate between "white" and the <body>
background color.
The setup to have fixed values for the calendar widget examples
broke the timestamp, and it would always show the same date.
Additionally, even the v4.3 doc was last updated this year (2021),
while there was no change to that version's code in three years.
CMake uses quotes and semicolon in its internal list datatype.
Previously, all double quotes were converted to single quotes to
avoid this problem. Semicolors were interpreted as newlines in
ldoc.
With this commit, both of them render fine. This was required
because a new example uses CSS and XML where those symbols have
a specific meanning.
For some even more strange reasons than commit 047729ae1, it seems
we can also have the error that `item.inherited` can be sets to `true`
on items that are not inherited...
I just had this issue with `wibox.widget.imagebox` where properties
were marked as inherited from `wibox.widget.imagebox`. Best way to fix
it is to only trust the check on `item.baseclass`, and completly
dismiss its `inherited` property.
Add a new ldoc tag `@hidden`. This tag allows us to keep documentation
for magic methods (e.g. `wibox.widget.base:get_visible`) but prevent
it from being part of the documentation used by final users.
For some reasons, sometime `item.inherited` is `false` even if the
item was added to the `all_module_kinds` table by the "hierarchy
lookup" for-loop, and we already force the `inherited` property to be
sets to `true` at this moment.
With this commit, we add a second fail-check condition based on the
`item.baseclass` property to determine if the item is inherited or not
when we do the render.
This commit adds a new ldoc custom tag `@supermodule`. It has to be
used at the module level. It should refer to the module
supermodules.
This tag can be used multiple time by the same module, but we ignore
other calls (for now?) as (AFAIK) we only use one way inheritance.
This tag is used in the ldoc template to find modules hierarchy and
draw the inheritance tree. It makes it easy to find and navigate to
parents modules.
* Add `@inheritedproperty`, `@inheritedmethod` and `@inheritedsignal` ldoc tags to specify inherited members in the documentation,
* These new tags create their own section in the rendered documentation,
* Implemente these tags for `docs/common/object.ldoc` and `docs/common/widget.ldoc`.
First of all, yes, JavaScript in the doc. I don't like this either.
The reason is that the new sections are super useful *when you need
them*. However, in practice, that's rare. So better not make the
signal to noise ratio worst. Future commit will introduce an
auto-generated summary of what's hidden.
It might not be the most pretty of change, but it works. With this
change, it is possible to have multiple "things" in the "same"
section having the "same" name.
This allows for C/C++ style functions with the same name but different
signatures. Lua doesn't handle this well, so it should usually be
avoided. However, constructors might be a valid exception. Most older
widget (and object) constructors have multiple random argument while
newer one use `args`. Deprecating the old ones for the sake of
standardization might be a bit too much for users upgrading from v3.5.
Given the only reason all of those deprecation would happen is because
"its pretty that way", then lets allow 2 constructors and avoid outrage.
For dubious reasons, ldoc uses the human readable name for the URLs
instead of the machine readable one. If the name has multiple words,
this causes the URLs to have spaces or %20 in them.
This commits remove all spaces from the "kinds" and then use `:gsub()`
in the template to convert underscores to spaces.
**WARNING** This breaks all URLs again. But this is necessary to prevent
broken links when the user paste them with spaces instead of %20.
Rather that abusing of how the arguments are displayed to convey the
type, add native support.
It still uses the @param for the doc, so this doesn't cause a million
little noisy changes, but the rendered HTML now have a real section for
the type. This is added to both the summary and the expanded description.
Additionally, if the type has a description string, a second is added.
Emmanuel Lepage Vallee
Aire-One
Lucas Schwiderski
Sergey
Aire-One
Daniel Hahler