The goal is to catch cases where the return value exists, but is
forgotten. There was a large enough number of them to turn this
into a real check. Initially, I just wanted to implement it to fix
the problems, then delete the code. But since this is so common, I
think it is worth the annoyance.
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.
It no longer does `foo(bar[,bar=42])` and will rather do `(foo, bar)`.
This is easier to read and some new user are no familiar with the
optional parameter convention. They copy/paste the mangled value in
their config and end up with invalid Lua.
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.
It was previously monkey-patching the input layout object into
the final tasklist.
This is a breaking change, but affects undocumented behaviors. By
doing this, it becomes possible to expose the properties in the
public API. This, in turn, allows to document them. Right now,
the documentation is very vague on some behaviors.
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.
The old behavior would move the client when `nil` was passed by
an almost arbitrary value. It would most of the time go off screen.
While this is a behavior change, what it replaces was so broken I
doubt anybody actually used `nil` in `relative_move`.
It might be a good idea to deprecate them and move them to the tag
class. However, these APIs are not exactly well designed, so
moving them wont solve that. Some day the dynamic client layout will
hopefully be merged and send these functions to the heap of smelly
bad ideas trash.
Emmanuel Lepage Vallee
Aire-One
Lucas Schwiderski
Mehdi YC
HumblePresent
Actionless Loveless
Sergey
paulhersch