Skip to content

Releases: elchininet/custom-sidebar

v8.4.0

18 Jan 20:59
Compare
Choose a tag to compare

This minor release brings some new features related to a new property in sidebar order items and possibility to work with reactive JavaScript variables.

Added a new property in order items

This release adds a new feature to make it possible to execute actions when clicking on sidebar items. With custom-sidebar it is possible to add an href property to each sidebar item making them redirect to an internal dashboard or to an external URL. From now on, it is also possible to execute certain actions when clicking on sidebar items. These actions can be executed at the same time that you are navigating to a dashboard or an external URL or can be exclusively executed if one omits the href property on new items or change it to # in existing ones.

Order items properties

Property Type Required Description
on_click OnClickAction no Specifies the onClick property of the sidebar item.
It allows two types of actions, ServiceCallAction
or JavaScriptAction. Take into account that setting this property
will not stop the href option for working. If you want to avoid
navigating to a page, you should set the href option
as # (in new items you can just omit it)
Service call actions

This action allows you to call a service clicking on an item of the sidebar

order:
  - new_item: true
    item: Example
    icon: mdi:gesture-tap
    on_click:
      action: call-service
      service: light.toggle
      data:
        entity_id: light.woonkamer
JavaScript actions

This action allows you to execute a JavaScript code (you don't need to wrap the code block between three square brackets)

order:
  - new_item: true
    item: Example
    icon: mdi:gesture-tap
    on_click:
      action: javascript
      code: |
        location.reload();

Use reactive variables in the templates

With this release, after the update of the home-assistant-javascript-templates package, it is also possible to make use of reactive variables in JavaScript templates. This will make your templates be reactive to variables only in the device in which you are working. For example, let's show or hide an item of the sidebar clicking on another item:

order:
  - new_item: true
    item: Example
    icon: mdi:gesture-tap
    on_click:
      action: javascript
      code: |
        const hide = ref('hide');
        hide.value = !hide.value;
  - item: history
    hide: |
      [[[
         const hide = ref('hide');
         if (hide.value === undefined) {
           hide.value = true;
         }
         return hide.value;
      ]]]

Reactive variables can also be declared in the js_variables property giving them an initial value. Let's refactor the previous code to declare the reactive variable hide in the js_variables property giving it an initial value there instead of giving the initial value in the item hide template:

js_variables:
  hide: ref(true)
order:
  - new_item: true
    item: Example
    icon: mdi:gesture-tap
    on_click:
      action: javascript
      code: |
        const hide = ref('hide');
        hide.value = !hide.value;
  - item: history
    hide: |
      [[[ ref('hide').value ]]]

IMPORTANT

  1. To make the templates detect that a reactive variable has been mutated, one needs to assign a new value to the reactive variable. For example, changing the items or an array using push or pop will not make the remplates using that variable to be reevaluated. You need to assign a new array to the value of the reactive variable to make the change been detected.
  2. To make the template aware that it contains a reactive variable, the value property of the variable should be accesed when the template is rendered. If the code accesing the value property is not executed when the template renders, then the reactive variable will not be tracked. That is why is recomendable to access the value property of the reactive variable outside any condition and build the logic using the retrieved value. In this way the template will track that the reactive variable is being used and any time that the variable changes, the template will get re-evaluated.

🚀 Features

  • Add an option to execute actions when clicking on sidebar items

🧩 Dependencies

  • Update home-assistant-javascript-templates package

📝 Documentation

  • Add an option to execute actions when clicking on sidebar items

📦 Other

v8.3.0

14 Jan 01:03
Compare
Choose a tag to compare

This minor release adds a new option to set the default URL path that should be redirected to when the page loads.

Configuration options

Property Type Required Description
default_path String no Defines the default URL path when the page loads. This path must start with /

IMPORTANT

The default_path option will change the default behaviour and every time that the page loads it will navigate to this path (either when the page loads for the first time or when it gets refreshed). If you don't want to have this behaviour and you would prefer to load Home Assistant in an specific path or refresh a specific page without being redirected to the default_path, then you should not set this option.


🚀 Features

  • Implement and option to set the default URL path on load

🧩 Dependencies

  • [Dependencies]: Bump typescript-eslint from 8.18.1 to 8.18.2 in the dependencies-dev group
  • [Dependencies]: Bump the dependencies-dev group with 2 updates
  • [Dependencies]: Bump the dependencies-dev group with 4 updates

📝 Documentation

v8.2.0

23 Dec 21:49
Compare
Choose a tag to compare

This release refactors the library to make it possible to set a template in the hide option of an item.

Order items properties

Property Type Required Description
hide* Boolean or String no Setting this property to true will hide the sidebar item
and if the property hide_all from the main configuration is true,
setting this property as false will avoid hiding this item

Tip

* These item properties allow JavaScript or Jinja templates.


🚀 Features

  • Make the "hide" option being configured also as a template

🧩 Dependencies

  • [Dependencies]: Bump the dependencies-dev group with 6 updates

📝 Documentation

  • Make the "hide" option being configured also as a template

v8.1.0

16 Dec 20:53
Compare
Choose a tag to compare

This release ships a new option to define the type of condition that will evaluate the exceptions' matchers:

Exceptions

Property Type Required Description
matchers_conditions "OR" | "AND" no Defines if at least one of the matchers
should match ("OR" which is the default value)
or if all the matchers should match ("AND")

If matchers_conditions is "OR" (default value), only one match from the matchers is needed for the exception to be picked. But if this option is "AND" then all of the matcher must match for the exception to be picked, in this case if any matcher does't match, then the exception will be discarded.

For example, the next exception will match the users with user name "John Doe" or "Jack Sparrow", the admin users or the users with a device Android (because matchers_conditions is by default "OR"):

...
exceptions:
  - user:
    - John Doe
    - Jack Sparrow
    is_admin: true
    device: Android
    order:
      ...

But the next exception will match all admins that are using an iPhone device excluding "ElChiniNet":

...
exceptions:
  - not_user: ElChiniNet
    is_admin: true
    device: iPhone
    matchers_conditions: AND
    order:
      ...

🚀 Features

  • Add an option to set the exceptions' matchers conditions

🧩 Dependencies

  • [Dependencies]: Bump the dependencies-dev group with 4 updates

📝 Documentation

  • Add an option to set the exceptions' matchers conditions

v8.0.1

14 Dec 23:32
Compare
Choose a tag to compare

v8.0.1

  • Update home-assistant-javascript-templates package

v8.0.0

This release is a major release of the plugin and it has breaking changes.

⚠️⚠️⚠️ Breaking Changes ⚠️⚠️⚠️

1. extend_from_base property has been removed from the exceptions config

If you want to have the previous functionality, you need to replace:

extend_from_base: true

by

extend_from: base

And remove any occurrence of:

extend_from_base: false

2. Exceptions are merged

Previously, if multiple exceptions match, the last one were the one used. From now on, if multiple exceptions match, they will be merged. Check the extendable configurations section for more info about how two configurations are merged.

3. Changed the merging logic of an exception extending from the base

Previously, when one exception extended from the base, the options that were in the exception remain, and the options that existed in the base but were not defined in the exception were extended. If both config had an order option, these were merged too, but if the two order options contained an item with the same item property, the last one ruled over the previous.

In this new version the first part remains the same, but the merging of two order options with items with the same item property changed. If two order options are merged and they contain one or more items with the same item property, they will be merged following the same logic: what is in the original item remains, what is in the extending one and not in the original item will be extended. Check the extendable configurations section for more info about how two configurations are merged.

Noteworthy Changes

1. js_variables and jinja_variables allow more variables types

Previously, js_variables and jinja_variables only allowed strings, numbers and booleans. Now it is possible to add more variable types. The next examples using js_variables and jinja_variables will set the same title ("Title 80 dog"):

js_variables example

js_variables:
  my_string: Title
  my_number: 100
  my_boolean: true
  my_object:
    prop1: 4
    prop2: 5
  my_array:
    - cat
    - dog
    - bird
title: |
  [[[
    if (my_boolean) {
      return `${my_string} ${(my_number * my_object.prop1) / my_object.prop2} ${my_array[1]}`;
    }
    return 'Home Assistant';
  ]]]

jinja_variables example

jinja_variables:
  my_string: Title
  my_number: 100
  my_boolean: true
  my_dictionary:
    prop1: 4
    prop2: 5
  my_list:
    - cat
    - dog
    - bird
title: |
  {% if my_boolean %}
    {{ my_string }} {{ ((my_number * my_dictionary.prop1) / my_dictionary.prop2) | int }} {{ my_list.1 }}
  {% else %}
    Home Assistant
  {% endif %}

2. New is_owner option in the exceptions

Now the exceptions configurations accept a new option is_owner.

Property Type Required Description
is_owner Boolean no Checks if the user is owner of the system.
This option can be set alone or combined with
user, not_user, device, not_device, or is_admin.
If it is used together with one of these options
they will be taken as conditions separated by a logical OR

3. Extendable configurations

Extendable configurations (extendable_configs) is an object containing different configurations options that could be extended from the main configuration, from the exceptions or from another extendable configuration, making them a very flexible option to share configuration blocks. To specify that a configuration should extend from an extendable configuration, the extend_from option should be used specifying the extendable configuration name(s).

Extending from a configuration basically means "import what I don't already have", so if a configuration already have an option, it will prevail and it will not be overridden if the configuration is extended. For example, the next configuration has a main configuration extending from an extendable configuration named example, let's analyse what will be the result of that extend.

title: Custom Title
order:
  - item: overview
    name: Dashboard
    order: 3
  - new_item: true
    item: Integrations
    href: "/config/integrations"
    icon: mdi:puzzle
    order: 2
extend_from: example
extendable_configs:
  example:
    title: My Home
    subtitle: Assistant
    order:
      - item: overview
        icon: mdi:monitor-dashboard
        order: 0
      - new_item: true
        item: Google
        href: https://mrdoob.com/projects/chromeexperiments/google-gravity/
        icon: mdi:earth
        target: _blank
        order: 1
  1. As the title option is defined in the main configuration, it will not get the title option from the extendable configuration.
  2. As the subtitle option is not defined in the main configuration, it will be get from the extendable configuration
  3. As the main configuration and the extendable configuration both have an order option, it will be merged:
    1. Both orders have an overview item, so it will be merged. As the main config order-item has also an order property, it will not be extended, but as the extendable order-item has an icon property that doesn't exist in the main config order-item, it will be extended
    2. As the extendable order-item doesn't have a name property, it will remain there
    3. The Integrations doesn't exist in the extendable order so it will remain as it is
    4. The Google extendable item doesn't exist in the main config, so it will be extended

The resulted main config after the extending process will be:

title: Custom Title
subtitle: Assistant
order:
  - new_item: true
    item: Google
    href: https://mrdoob.com/projects/chromeexperiments/google-gravity/
    icon: mdi:earth
    target: _blank
    order: 1
  - new_item: true
    item: Integrations
    href: "/config/integrations"
    icon: mdi:puzzle
    order: 2
  - item: overview
    name: Dashboard
    icon: mdi:monitor-dashboard
    order: 3
  

It is possible to extend from multiple configurations and they will be extended in order, as shown in the next example:

extend_from:
  - colors
  - titles
extendable_configs:
  colors:
    icon_color: red
    text_color: red
  titles:
    title: Custom Title
    subtitle: Custom Subtitle

As already mentioned, an extendable configuration can extend from other extendable configurations:

title: Custom Title
extend_from: example
extendable_configs:
  colorful:
    title_color: red,
    subtitle_color: blue
  example:
    subtitle: Assistant
    extend_from: colorful

The resulted main config will be:

title: Custom Title
subtitle: Assistant
title_color: red,
subtitle_color: blue

In the case of exceptions, they can also extend from the main configuration if base is used in the extend_from option:

title: Custom Title
extend_from: example
extendable_configs:
  colorful:
    title_color: red,
    subtitle_color: blue
  example:
    subtitle: Assistant
    extend_from: colorful
exceptions:
  - user:
    - ElChiniNet
    order:
      - item: overview
        name: Dashboard
        icon: mdi:monitor-dashboard
        order: 3
    extend_from: base

So, the configuration for the user ElChiniNet will be the same previous main config, plus an order with an order-item.

The next example is a more complex one extending from multiple configurations:

title: My Home
extend_from: admin_config
order:
  - new_item: true
    item: Google
    href: https://mrdoob.com/projects/chromeexperiments/google-gravity/
    icon: mdi:earth
    target: _blank
    order: 1
extendable_configs:
  multicolor:
    icon_color: red
    icon_color_selected: blue
    icon_color_hover: green
    text_color: red
    text_color_selected: blue
    text_color_hover: green
  admin_config:
    order:
      - new_item: true
        item: Integrations
        href: "/config/integrations"
        icon: mdi:puzzle
        order: 2
      - new_item: true
        item: Entities
        href: "/config/entities"
        icon: mdi:hexagon-multiple
        order: 3
  user_config:
    extend_from: multicolor
    hide_all: true
    order:
      - item: overview
        hide: false
exceptions:
  - is_admin: true
    extend_from:
      - multicolor
      - admin_config
    order:
      - item: config
        bottom: true
  - user:
    - ElChiniNet
    - Palaus
    etend_from: base
    title: HA
  - user:
    - Jim Hawkins
    - Long John Silver
    extend_from: user_config
    order:
      - item: overview
        name: Dashboard

Important

  • You need to be careful of circular dependencies when extending configurations, if this is detected an error will be thrown
  • You can only use base inside extend_from if you are in an exception, trying to use it in the main config or in an extendable configuration will throw and error

🛠 Fixes

  • Update home-assistant-javascript-templates package

🧩 Dependencies

  • Update home-assistant-javascript-templates package

⚙️ Configuration

  • Update Home Assistant Docker image to version 2024.12.2
    ...
Read more

v8.0.0

11 Dec 01:03
Compare
Choose a tag to compare

This release is a major release of the plugin and it has breaking changes.

⚠️⚠️⚠️ Breaking Changes ⚠️⚠️⚠️

1. extend_from_base property has been removed from the exceptions config

If you want to have the previous functionality, you need to replace:

extend_from_base: true

by

extend_from: base

And remove any occurrence of:

extend_from_base: false

2. Exceptions are merged

Previously, if multiple exceptions match, the last one were the one used. From now on, if multiple exceptions match, they will be merged. Check the extendable configurations section for more info about how two configurations are merged.

3. Changed the merging logic of an exception extending from the base

Previously, when one exception extended from the base, the options that were in the exception remain, and the options that existed in the base but were not defined in the exception were extended. If both config had an order option, these were merged too, but if the two order options contained an item with the same item property, the last one ruled over the previous.

In this new version the first part remains the same, but the merging of two order options with items with the same item property changed. If two order options are merged and they contain one or more items with the same item property, they will be merged following the same logic: what is in the original item remains, what is in the extending one and not in the original item will be extended. Check the extendable configurations section for more info about how two configurations are merged.

Noteworthy Changes

1. js_variables and jinja_variables allow more variables types

Previously, js_variables and jinja_variables only allowed strings, numbers and booleans. Now it is possible to add more variable types. The next examples using js_variables and jinja_variables will set the same title ("Title 80 dog"):

js_variables example

js_variables:
  my_string: Title
  my_number: 100
  my_boolean: true
  my_object:
    prop1: 4
    prop2: 5
  my_array:
    - cat
    - dog
    - bird
title: |
  [[[
    if (my_boolean) {
      return `${my_string} ${(my_number * my_object.prop1) / my_object.prop2} ${my_array[1]}`;
    }
    return 'Home Assistant';
  ]]]

jinja_variables example

jinja_variables:
  my_string: Title
  my_number: 100
  my_boolean: true
  my_dictionary:
    prop1: 4
    prop2: 5
  my_list:
    - cat
    - dog
    - bird
title: |
  {% if my_boolean %}
    {{ my_string }} {{ ((my_number * my_dictionary.prop1) / my_dictionary.prop2) | int }} {{ my_list.1 }}
  {% else %}
    Home Assistant
  {% endif %}

2. New is_owner option in the exceptions

Now the exceptions configurations accept a new option is_owner.

Property Type Required Description
is_owner Boolean no Checks if the user is owner of the system.
This option can be set alone or combined with
user, not_user, device, not_device, or is_admin.
If it is used together with one of these options
they will be taken as conditions separated by a logical OR

3. Extendable configurations

Extendable configurations (extendable_configs) is an object containing different configurations options that could be extended from the main configuration, from the exceptions or from another extendable configuration, making them a very flexible option to share configuration blocks. To specify that a configuration should extend from an extendable configuration, the extend_from option should be used specifying the extendable configuration name(s).

Extending from a configuration basically means "import what I don't already have", so if a configuration already have an option, it will prevail and it will not be overridden if the configuration is extended. For example, the next configuration has a main configuration extending from an extendable configuration named example, let's analyse what will be the result of that extend.

title: Custom Title
order:
  - item: overview
    name: Dashboard
    order: 3
  - new_item: true
    item: Integrations
    href: "/config/integrations"
    icon: mdi:puzzle
    order: 2
extend_from: example
extendable_configs:
  example:
    title: My Home
    subtitle: Assistant
    order:
      - item: overview
        icon: mdi:monitor-dashboard
        order: 0
      - new_item: true
        item: Google
        href: https://mrdoob.com/projects/chromeexperiments/google-gravity/
        icon: mdi:earth
        target: _blank
        order: 1
  1. As the title option is defined in the main configuration, it will not get the title option from the extendable configuration.
  2. As the subtitle option is not defined in the main configuration, it will be get from the extendable configuration
  3. As the main configuration and the extendable configuration both have an order option, it will be merged:
    1. Both orders have an overview item, so it will be merged. As the main config order-item has also an order property, it will not be extended, but as the extendable order-item has an icon property that doesn't exist in the main config order-item, it will be extended
    2. As the extendable order-item doesn't have a name property, it will remain there
    3. The Integrations doesn't exist in the extendable order so it will remain as it is
    4. The Google extendable item doesn't exist in the main config, so it will be extended

The resulted main config after the extending process will be:

title: Custom Title
subtitle: Assistant
order:
  - new_item: true
    item: Google
    href: https://mrdoob.com/projects/chromeexperiments/google-gravity/
    icon: mdi:earth
    target: _blank
    order: 1
  - new_item: true
    item: Integrations
    href: "/config/integrations"
    icon: mdi:puzzle
    order: 2
  - item: overview
    name: Dashboard
    icon: mdi:monitor-dashboard
    order: 3
  

It is possible to extend from multiple configurations and they will be extended in order, as shown in the next example:

extend_from:
  - colors
  - titles
extendable_configs:
  colors:
    icon_color: red
    text_color: red
  titles:
    title: Custom Title
    subtitle: Custom Subtitle

As already mentioned, an extendable configuration can extend from other extendable configurations:

title: Custom Title
extend_from: example
extendable_configs:
  colorful:
    title_color: red,
    subtitle_color: blue
  example:
    subtitle: Assistant
    extend_from: colorful

The resulted main config will be:

title: Custom Title
subtitle: Assistant
title_color: red,
subtitle_color: blue

In the case of exceptions, they can also extend from the main configuration if base is used in the extend_from option:

title: Custom Title
extend_from: example
extendable_configs:
  colorful:
    title_color: red,
    subtitle_color: blue
  example:
    subtitle: Assistant
    extend_from: colorful
exceptions:
  - user:
    - ElChiniNet
    order:
      - item: overview
        name: Dashboard
        icon: mdi:monitor-dashboard
        order: 3
    extend_from: base

So, the configuration for the user ElChiniNet will be the same previous main config, plus an order with an order-item.

The next example is a more complex one extending from multiple configurations:

title: My Home
extend_from: admin_config
order:
  - new_item: true
    item: Google
    href: https://mrdoob.com/projects/chromeexperiments/google-gravity/
    icon: mdi:earth
    target: _blank
    order: 1
extendable_configs:
  multicolor:
    icon_color: red
    icon_color_selected: blue
    icon_color_hover: green
    text_color: red
    text_color_selected: blue
    text_color_hover: green
  admin_config:
    order:
      - new_item: true
        item: Integrations
        href: "/config/integrations"
        icon: mdi:puzzle
        order: 2
      - new_item: true
        item: Entities
        href: "/config/entities"
        icon: mdi:hexagon-multiple
        order: 3
  user_config:
    extend_from: multicolor
    hide_all: true
    order:
      - item: overview
        hide: false
exceptions:
  - is_admin: true
    extend_from:
      - multicolor
      - admin_config
    order:
      - item: config
        bottom: true
  - user:
    - ElChiniNet
    - Palaus
    etend_from: base
    title: HA
  - user:
    - Jim Hawkins
    - Long John Silver
    extend_from: user_config
    order:
      - item: overview
        name: Dashboard

Important

  • You need to be careful of circular dependencies when extending configurations, if this is detected an error will be thrown
  • You can only use base inside extend_from if you are in an exception, trying to use it in the main config or in an extendable configuration will throw and error

🚀 Features

🧩 Dependencies

  • [Dependencies]: Bump the dependencies-dev group with 3 updates

📝 Documentation

v7.2.0

07 Dec 14:22
Compare
Choose a tag to compare

This release adds a new option to the exceptions to filter by admin/non admin users.

Exceptions

Property Type Required Description
is_admin Boolean no Checks if the user is admin or not.
This option can be set alone.
or combined with user, not_user,.
device or not_device If it is used together.
with one of these options they will be taken.
as conditions separated by a logical OR

🚀 Features

v7.1.0

04 Dec 19:56
Compare
Choose a tag to compare

This release adds a new option to hide all the sidebar items by default.

Configuration options

Property Type Required Description
hide_all Boolean no Hides all items of the sidebar by default,
useful if one wants to hide everything and just show a few items.
(This options doesn't make any effect in an item with the property
new_item in true)

🚀 Features

🧩 Dependencies

⚙️ Configuration

📝 Documentation

📦 Other

v7.0.0

24 Nov 12:34
Compare
Choose a tag to compare

⚠️⚠️⚠️ BREAKING CHANGE ⚠️⚠️⚠️

This is a major refactor of the library and it will bump it to a major version because there are breaking changes.

1. New option to se the background of a sidebar item

Property Type Required Description
item_background* String no Sets the background of the sidebar items.
It could be a color or a background declaration

2. New options to set the selected state of notifications

Property Type Required Description
notification_color_selected* String no Sets the color of the sidebar notification
of the selected sidebar item
notification_text_color_selected* String no Sets the color of the sidebar notification texts
of the selected sidebar item

3. New options to set the hover state of the sidebar item elements

Property Type Required Description
item_background_hover* String no Sets the background of the sidebar items
in a hover state.
It could be a color or a background declaration
icon_color_hover* String no Sets the icon color of the sidebar items
in a hover state
text_color_hover* String no Sets the text color of the sidebar items
in a hover state
info_color_hover* String no Sets the color of the info texts
in a hover state
notification_color_hover* String no Sets the color of the sidebar notification
when the item is in hover state
notification_text_color_hover* String no Sets the color of the sidebar notifications texts
when the item is in hover state

4. Renamed some variables

Some variables were renamed to match them with the naming of the rest of the options

  • --custom-sidebar-selected-text-color to --custom-sidebar-text-color-selected
  • --custom-sidebar-selected-icon-color to --custom-sidebar-icon-color-selected
  • --custom-sidebar-selected-info-color to --custom-sidebar-info-color-selected

5. The selection_color option has been replaced by selection_background

This option now accepts a color or a background declaration

6. Fix a bug that was provoking that the Notifications item was not affected by the selection_background option

7. Refactoring of the code

The code has been refactored to separate better the style and the variables. It was becoming a mess to make an update because it was hard to find the style block. Several enums have been created to avoid unnecessary repetitions and make it less likely to make a mistake when a new option is added.

Tip

* These options allow JavaScript or Jinja templates.


🚀 Features

🛠 Fixes

🧩 Dependencies

  • [Dependencies]: Bump cross-spawn from 7.0.3 to 7.0.5
  • [Dependencies]: Bump home-assistant-javascript-templates from 5.4.2 to 5.5.0 in the dependencies-prod group
  • [Dependencies]: Bump the dependencies-dev group across 1 directory with 4 updates
  • [Dependencies]: Bump the dependencies-dev group with 4 updates

📝 Documentation

📦 Other

  • Refactor CSS variables validation and management
  • Avoid code repetition creating options variables map constants

v6.8.0

16 Nov 20:27
Compare
Choose a tag to compare

Added two new options to colorise both sidebar dividers independently (divider_top_color and divider_botom_color).

Configuration options

Property Type Required Description
divider_color* String no Sets the color of both sidebar dividers
divider_top_color* String no Sets the color of the top sidebar divider. It overrides divider_color for this divider if it is set
divider_bottom_color* String no Sets the color of the bottom sidebar divider. It overrides divider_color for this divider if it is set

Tip

* These options allow JavaScript or Jinja templates.


🚀 Features

  • Add options to colorise both dividers independently

🧩 Dependencies

  • [Dependencies]: Bump @eslint/plugin-kit from 0.2.2 to 0.2.3

📝 Documentation

  • Add options to colorise both dividers independently