f5851ee00d
* Expose `ScrollBarStyle` webview option to tauri. This commit exposes the scroll_bar_style option from wry via the tauri WebviewWindowBuilder API. By itself, the commit does not include changes to the configuration file or JavaScript APIs: These will be added in a later commit. * Fix a compile error on macOS and Linux. * Add `scroll_bar_style` to WindowConfig. This commit exposes the `scroll_bar_style` option in tauri.conf.json/ .json5/.toml as `scrollBarStyle` and `scroll-bar-style`. * Expose `scroll_bar_style` to JavaScript API. This commit exposes the `scroll_bar_style` in the options object passed to the JavaScript API `Webview` and `WebviewWindow` constructors. While testing this, I discovered that on Windows, attempting to create a webview from the JavaScript API will cause the hosting window to immediately hang if it attempts to use the same data directory as another webview without sharing the same environment options. This commit includes no mitigation for this behaviour, as I will be opening a separate issue about it at some point in the near future. * Document WebView2 environment requirements. This commit adds a message to the documentation for all components of the `scroll_bar_style` configuration option, telling users that all webviews that use the same data directory must use the same value for this option. * Fix formatting. * Add change files to .changes directory. * Remove `tauri-schema-generator` from change file. * Remove quotes from change tags. * Add tags to change files. I did not realise that these were needed, as the pull request that I used as my reference when building this feature did not have them. * update conf --------- Co-authored-by: Lucas Nogueira <lucas@tauri.app>
Changes
via https://github.com/jbolda/covector
As you create PRs and make changes that require a version bump, please add a new markdown file in this folder. You do not note the version number, but rather the type of bump that you expect: major, minor, or patch. The filename is not important, as long as it is a .md, but we recommend that it represents the overall change for organizational purposes.
When you select the version bump required, you do not need to consider dependencies. Only note the package with the actual change, and any packages that depend on that package will be bumped automatically in the process.
Use the following format:
---
'package-a': 'patch:enhance'
'package-b': 'patch:enhance'
---
Change summary goes here
Summaries do not have a specific character limit, but are text only. These summaries are used within the (future implementation of) changelogs. They will give context to the change and also point back to the original PR if more details and context are needed.
Changes will be designated as a major, minor or patch as further described in semver.
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards compatible manner, and
- PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format, but will be discussed prior to usage (as extra steps will be necessary in consideration of merging and publishing).
Additionally you could specify a tag for the change file to group it with other changes by prefixing the bump with :<tag>, for example:
---
'package-a': 'patch:enhance'
---
Change summary goes here
which will group this change file with other changes that specify the bug tag.
For list of available tags, see the changeTags key in ./config.json