* Popover: fixed a bug that a node value was not being set
* PlatformUtils: fixed a bug that MacOS can be an OS with name darwin
* Optimized switch statements
* Code formatting and cleanup
* Removed unused imports
* Reformat markdown tables
* Use try-with-resources
* Improve Javadoc
* Enforce Git compliance
* Better NPE error messages
* Fixed spelling errors
- Support adding top/bottom node to embed custom user widgets
- Move prev/next arrows to the right side
- Add clock example
- Add show/hide header example
- Fix unreadable next month today fg color
- Use opacity for hover effect
- Add color transition for focused effect
- Add separate hover effect for SplitMenuButton arrow
- Add button color customization example
Supposed to be used when component is placed within another control that already provides external borders. Should not be confused with 'no-border' style. Some controls in the 'edge-to-edge' mode still need a border, e.g. toolbar always needs the bottom border.
The main problem of the old approach is that variables which contain real color
name (blue, green, red) were exposed as looked-up colors. This is because
GitHub Primer only specifies four functional variables for each color
(foreground, emphasis, muted and subtle) and only three of them can be used as
background color, which is clearly not enough to create hover, pressed or other
color effects. So, we can either use dynamic color modification functions,
which can lead to less predictable results, or use colors from the predefined
color palette, or create a bunch of the ugly named color variables for every
combination (`-color-accent-muted-hover`, `-color-accent-subtle-hover` and so
on) for general purposes.
Still, it worked fine until changing accent color feature wasn't implemented.
To fully change accent or any other color, one should change not only the
functional variables, but also the corresponding color scale, which is
responsible for background effects. As an outcome, if we change the accent
color to purple, we end-up with `-color-accent-emphasis` which is purple and
`-color-blue-5`which is also purple. That's just confusing.
This commit resolves this by renaming all color scale stuff to functional
variables. So, `-color-blue-*` becomes `-color-accent-*` and so on, and this
long explanation supposed to serve as a reminder that nothing is perfect and
this is just another trade-off example.
Color shades should be declared upfront without resorting to the dynamic brightness modification functions. All shades are also exposed as looked-up colors.
