diff --git a/.github/workflows/upgrade_version.yaml b/.github/workflows/upgrade_version.yaml index d75603b327a..0990883c33c 100644 --- a/.github/workflows/upgrade_version.yaml +++ b/.github/workflows/upgrade_version.yaml @@ -47,6 +47,9 @@ jobs: sed -i 's/GIT_TAG v[0-9]*\.[0-9]*\.[0-9]*/GIT_TAG v${{ github.event.inputs.new_version }}/' api/cpp/esp-idf/slint/CMakeLists.txt sed -i 's/find_package(Slint [0-9]*\.[0-9]*\.[0-9]*)/find_package(Slint ${{ github.event.inputs.new_version }})/' api/cpp/esp-idf/slint/CMakeLists.txt + # Version in the Android docs + sed -i 's/^slint = { version = "[^"]+"/slint = { version = "${{ github.event.inputs.new_version }}"/' docs/astro/src/content/docs/guide/platforms/mobile/android.mdx + echo "Note that the version is not updated in the documentation and README yet" - name: Commit @@ -68,34 +71,34 @@ jobs: id: app-token uses: actions/create-github-app-token@v2 with: - app-id: ${{ vars.READ_WRITE_APP_ID }} - private-key: ${{ secrets.READ_WRITE_PRIVATE_KEY }} - repositories: www-releases + app-id: ${{ vars.READ_WRITE_APP_ID }} + private-key: ${{ secrets.READ_WRITE_PRIVATE_KEY }} + repositories: www-releases - name: Clone www-releases directory uses: actions/checkout@v5 with: - repository: slint-ui/www-releases - sparse-checkout: | - releases/versions.json - path: www-releases - token: ${{ steps.app-token.outputs.token }} + repository: slint-ui/www-releases + sparse-checkout: | + releases/versions.json + path: www-releases + token: ${{ steps.app-token.outputs.token }} - name: Update version in versions.json run: | - sed -i '0,/"version": "[0-9]\+\.[0-9]\+\.[0-9]\+"/s//"version": "${{ github.event.inputs.new_version }}"/' www-releases/releases/versions.json + sed -i '0,/"version": "[0-9]\+\.[0-9]\+\.[0-9]\+"/s//"version": "${{ github.event.inputs.new_version }}"/' www-releases/releases/versions.json - name: Adjust redirections run: | - sed -i "/\/[0-9]*\.[0-9]*\.[0-9]*\/* https:\/\/snapshots\.slint\.dev\/master\/:splat/ s/[0-9]*\.[0-9]*\.[0-9]*/${{ github.event.inputs.new_version }}/" www-releases/releases/_redirects + sed -i "/\/[0-9]*\.[0-9]*\.[0-9]*\/* https:\/\/snapshots\.slint\.dev\/master\/:splat/ s/[0-9]*\.[0-9]*\.[0-9]*/${{ github.event.inputs.new_version }}/" www-releases/releases/_redirects - name: Get GitHub App User ID id: get-user-id run: echo "user-id=$(gh api "/users/${{ steps.app-token.outputs.app-slug }}[bot]" --jq .id)" >> "$GITHUB_OUTPUT" env: - GH_TOKEN: ${{ steps.app-token.outputs.token }} + GH_TOKEN: ${{ steps.app-token.outputs.token }} - name: commit and push working-directory: ./www-releases run: | - git config user.name '${{ steps.app-token.outputs.app-slug }}[bot]' - git config user.email '${{ steps.get-user-id.outputs.user-id }}+${{ steps.app-token.outputs.app-slug }}[bot]@users.noreply.github.com>' - git add . - git add -u . - git commit --message "Update $NAME from $GITHUB_REPOSITORY" --message "Update versions.json" - git push + git config user.name '${{ steps.app-token.outputs.app-slug }}[bot]' + git config user.email '${{ steps.get-user-id.outputs.user-id }}+${{ steps.app-token.outputs.app-slug }}[bot]@users.noreply.github.com>' + git add . + git add -u . + git commit --message "Update $NAME from $GITHUB_REPOSITORY" --message "Update versions.json" + git push diff --git a/REUSE.toml b/REUSE.toml index f363a578aaf..f1d277e217e 100644 --- a/REUSE.toml +++ b/REUSE.toml @@ -283,3 +283,9 @@ path = ["ui-libraries/material/src/ui/icons/**.svg", "ui-libraries/material/exam precedence = "aggregate" SPDX-FileCopyrightText = "Material Icons " SPDX-License-Identifier = "Apache-2.0" + +[[annotations]] +path = ["docs/astro/src/assets/android/**.png"] +precedence = "aggregate" +SPDX-FileCopyrightText = "Copyright © SixtyFPS GmbH " +SPDX-License-Identifier = "CC-BY-4.0" diff --git a/docs/astro/astro.config.mjs b/docs/astro/astro.config.mjs index 89de48b167b..04e25a7771d 100644 --- a/docs/astro/astro.config.mjs +++ b/docs/astro/astro.config.mjs @@ -160,8 +160,15 @@ export default defineConfig({ items: [ "guide/platforms/desktop", "guide/platforms/embedded", - "guide/platforms/android", - "guide/platforms/ios", + { + label: "Mobile", + collapsed: true, + items: [ + "guide/platforms/mobile/general", + "guide/platforms/mobile/android", + "guide/platforms/mobile/ios", + ], + }, "guide/platforms/web", "guide/platforms/other", ], diff --git a/docs/astro/src/assets/android/android_keyboard_settings.png b/docs/astro/src/assets/android/android_keyboard_settings.png new file mode 100644 index 00000000000..1680e6724e5 Binary files /dev/null and b/docs/astro/src/assets/android/android_keyboard_settings.png differ diff --git a/docs/astro/src/assets/android/android_sdk_manager.png b/docs/astro/src/assets/android/android_sdk_manager.png new file mode 100644 index 00000000000..b0cc5493125 Binary files /dev/null and b/docs/astro/src/assets/android/android_sdk_manager.png differ diff --git a/docs/astro/src/assets/android/android_virtual_device_manager.png b/docs/astro/src/assets/android/android_virtual_device_manager.png new file mode 100644 index 00000000000..fc1c61e2704 Binary files /dev/null and b/docs/astro/src/assets/android/android_virtual_device_manager.png differ diff --git a/docs/astro/src/assets/android/android_virtual_device_manager_menu.png b/docs/astro/src/assets/android/android_virtual_device_manager_menu.png new file mode 100644 index 00000000000..be6c8b25031 Binary files /dev/null and b/docs/astro/src/assets/android/android_virtual_device_manager_menu.png differ diff --git a/docs/astro/src/assets/android/android_virtual_keyboard_stylus.png b/docs/astro/src/assets/android/android_virtual_keyboard_stylus.png new file mode 100644 index 00000000000..2bed076331b Binary files /dev/null and b/docs/astro/src/assets/android/android_virtual_keyboard_stylus.png differ diff --git a/docs/astro/src/content/docs/guide/platforms/android.mdx b/docs/astro/src/content/docs/guide/platforms/android.mdx deleted file mode 100644 index 8a4d9f1237d..00000000000 --- a/docs/astro/src/content/docs/guide/platforms/android.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- - -title: Android -description: Android Platform Guide ---- - -import LangRefLink from '@slint/common-files/src/components/LangRefLink.astro'; - -Slint on Android is only supported for the Rust programming language. -See the documentation of the android module in our Rust API documentation. diff --git a/docs/astro/src/content/docs/guide/platforms/mobile/android.mdx b/docs/astro/src/content/docs/guide/platforms/mobile/android.mdx new file mode 100644 index 00000000000..cbf5db7bfa0 --- /dev/null +++ b/docs/astro/src/content/docs/guide/platforms/mobile/android.mdx @@ -0,0 +1,198 @@ +--- + +title: Android +description: Android Platform Guide +--- + +// cSpell: ignore xbuild textfields + +import LangRefLink from '@slint/common-files/src/components/LangRefLink.astro'; +import { Image } from 'astro:assets'; + +:::note[Note] +When developing Slint applications for Android, you can only use Rust as the programming language. +::: + +Also see the documentation of the android module in our Rust API documentation. + +## Project Setup + +Slint uses the [android-activity crate](https://github.com/rust-mobile/android-activity) as the interface to +the operating system, which is re-exported as `slint::android::android_activity`. To get started, follow these steps: + +First, your project needs to be a library crate. Add the following to your `Cargo.toml`: + +```toml +[lib] +crate_type = ["cdylib"] +``` + +You also need to select the version of android-activity you want to use: + +```toml +[dependencies] +slint = { version = "1.15.0", features = ["backend-android-activity-06"] } +``` + +This feature compiles with any target\_os and can safely be enabled anywhere. + +Second, in your `lib.rs`, add this function: + +```rs +#[cfg(target_os = "android")] +#[unsafe(no_mangle)] +fn android_main(app: slint::android::AndroidApp) { + slint::android::init(app).unwrap(); + let main_window = ...; // window generated by the Slint macros + main_window.run().unwrap(); +} +``` + +You can also add an Android event +([`android_activity::PollEvent`](https://docs.rs/android-activity/latest/android_activity/enum.PollEvent.html)) +listener by replacing the call to `slint::android::init` with `slint::android::init_with_event_listener`. + +That's all of the necessary code changes. In the next section, we're going to set up the environment to +build the project. + +## Android Setup + +The Android development workflow centers around the `adb` command line tool. Use it to connect to +Android devices and emulators to upload and run applications (and do other things not relevant here). + +The easiest way to install the Android development environment is to download and install +[Android Studio](https://developer.android.com/studio). In the settings pane, navigate to the Android +SDK page and install all SDK versions you need. We recommend to use the latest version available, +because it can be configured to be backwards-compatible with older versions of Android. This manager +is available in the settings in "Languages & Frameworks" > "Android SDK". + +import androidSdkManager from '/src/assets/android/android_sdk_manager.png'; + +Screenshot Android SDK Manager + +Also note the SDK location on top, this path might have to be used for the `ANDROID_HOME` environment +variable if the build tools can't detect it automatically. + +Add the `platform-tools` directory to your `PATH` so that the `adb` tool is available on the command +line. + +To get the list of Android devices, simulators and emulators currently attached to your machine, run + +```sh +adb devices +``` + +You can connect to a physical device on the network by using + +```sh +adb connect +``` + +The `host` is the IP address of the device. Note that it has to have development mode enabled for +this. + +### Virtual Device Setup + +We recommend developing using a virtual device first, because it speeds up the development cycle. +However, eventually you have to also test on a device to make sure that the interface is usable on a +touch screen and to check if all text is large enough, etc. + +To create and run a virtual device, use the Virtual Device Manager available in Android Studio. You +can open it from its main screen under "More Actions": + +import virtualDeviceManagerMenuItem from '/src/assets/android/android_virtual_device_manager_menu.png'; + +Screenshot Virtual Device Manager Menu Item + +You can create any number of devices with different configurations here: + +import virtualDeviceManager from '/src/assets/android/android_virtual_device_manager.png'; + +Screenshot Virtual Device Manager + +A good approach is to have one device with the minimum API level supported by your application and +another one with the latest release to make sure it runs on both. + +Running virtual devices connect to `adb` automatically. + +#### Virtual Keyboard + +Note that depending on the device template you pick, the virtual devices created here might use a +hardware keyboard by default, which is not helpful for testing your application. Unfortunately, we +were unable to locate a way to disable it in the Virtual Device Manager directly. + +To fix this, click on the three vertical dots next to the device in the manager to open up the menu +and select "Show on disk". In the directory that now opens, open the file `config.ini` in your +favorite text editor. Navigate to the line `hw.keyboard=yes` and change it to `hw.keyboard=no`, then +save the file. + +The next challenge is that there is still no keyboard: + +import virtualKeyboardStylus from '/src/assets/android/android_virtual_keyboard_stylus.png'; + +Screenshot Stylus Support + +Disable the stylus input in the keyboard settings: + +import keyboardSettings from '/src/assets/android/android_keyboard_settings.png'; + +Screenshot Keyboard Settings + +Select "Write in textfields" in the list and then disable that feature. This enables the +regular virtual keyboard. + +### Running the Application + +There are multiple ways to build, upload and run Android apps written in Rust. This page describes a +way using [xbuild](https://github.com/rust-mobile/xbuild). This doesn't use Android Studio at all. + +At the time of this writing, the current version of xbuild (0.2.0) is severely outdated and contains +relevant bugs that have been fixed in the master branch. So, don't use `cargo install xbuild` to +install it, use the git version instead: + +```sh +cargo install --git https://github.com/rust-mobile/xbuild.git +``` + +The command line tool for xbuild is simply called `x`. For example, to get a list of devices connected, +use + +```sh +x devices +``` + +Note that unlike `adb` above, this tool also supports iOS devices and simulators. However, for Android +devices it simply talks to `adb`, so if you connect a device using that tool, it will also show up here. + +To build your project, navigate to the directory containing your `Cargo.toml` and run + +```sh +x run --device +``` + +Where `` is shown in `x devices` as the leftmost column and is something like `adb:emulator-1234` +for virtual Android devices. + +This should build your project, upload it to the device and run it. The target platform is detected +automatically. + +To recompile and test changes, press ctrl-c and run the same command again. The running version on the +device is replaced automatically. + +#### Troubleshooting + +If `x run` doesn't work, run `x doctor` to check if you have all required tools installed and that +they're found by xbuild. + +### Building + +There are many ways to distribute Android applications and xbuild supports all of them via `x build`. +To get information about the configuration, use `x build --help`. + +For example, to build an .apk file, use something like + +```sh +x build --platform android --arch arm64 --format apk --release +``` + +The apk is then located in `target/x/release/android/.apk`. diff --git a/docs/astro/src/content/docs/guide/platforms/mobile/general.mdx b/docs/astro/src/content/docs/guide/platforms/mobile/general.mdx new file mode 100644 index 00000000000..6d1e521fcda --- /dev/null +++ b/docs/astro/src/content/docs/guide/platforms/mobile/general.mdx @@ -0,0 +1,177 @@ +--- + +title: General Mobile Development +description: Mobile development guide +--- + +import { Code } from '@astrojs/starlight/components'; +import Link from '@slint/common-files/src/components/Link.astro'; +import { Image } from 'astro:assets'; + +:::note[Note] +When developing Slint applications for Android or iOS, you can only use Rust as the programming language for now. +::: + +While Slint is used in the same way for mobile and desktop applications, there are a few things that have to be kept in +mind during development. Mobile platforms usually feature a small screen and no hardware keyboard, which have direct +consequences that can't be handled by the user interface framework, but are specific to the application. Touch +interfaces also need special handling as opposed to mouse-based interaction. + +This page describes considerations that apply to all mobile platforms. The next pages dive into platform-specific +issues on top of these. + +## Scrolling + +By default, Slint s only scroll by dragging the scrollbar or the mouse wheel. This is fine for desktop, but +touch interfaces are expected to scroll while panning the whole view. + +Enable it in Slint like this: + +```slint +import { ScrollView } from "std-widgets.slint"; +export component MyComponent { + ScrollView { + mouse-drag-pan-enabled: true; + + // Your own elements here + } +} +``` + +Note that this also enables the behavior when a mouse is attached, which might not be desired. This will be fixed in +a future version of Slint. + +## Safe Area + +Operating system developers for mobile devices try to improve the limitations of the small screen by reducing the amount +of system-level overlays to a bare minimum. This means that applications usually have access to the entire screen, but +there are a few system items overlaid, for example the cell tower reception and battery status. On Android, this also +includes navigation buttons. Also, many cellphone devices embed the front-facing camera into the display, leaving only a +small non-rectangular area inaccessible ("the notch"). + +Apps can usually draw onto the entire screen and underneath certain overlay areas, but user interaction is not allowed +everywhere. For example, buttons drawn underneath the front-facing camera area can't be tapped. Therefore, Android and +iOS describe what's called a "safe area": A rectangular region where an application can expect users to be able to +interact with interface elements. It is defined by an inset, meaning that it defines the thickness of an invisible +border inside the application's window which should only contain background elements (like background images, patterns, +color). This safe area can also change in size at runtime, for example on Android when the navigation buttons at the +bottom are shown and hidden. + +In Slint, this area is exposed with four properties on the element: + +* +* +* +* + +If you want to place a rectangle to visualize the safe area, for example for debugging, you can do it like this: + +```slint +export component MainWindow inherits Window { + Rectangle { + background: yellow; + x: root.safe-area-inset-left; + y: root.safe-area-inset-top; + width: root.width - root.safe-area-inset-right - root.safe-area-inset-left; + height: root.height - root.safe-area-inset-bottom - root.safe-area-inset-top; + } +} +``` + +## Keyboard Handling + +Since the introduction of the iPhone, modern smartphones usually don't feature a hardware keyboard for text input. There are +accessories like Bluetooth or USB keyboards and special phone cases that do provide such a feature, but there always has to +be a software fallback, the "virtual keyboard". + +Note that the keyboard is not always comprised of rows of buttons, it can also be a handwriting recognition area, voice +input, or a camera viewer for capturing text or bar codes that are then inserted. All of these are handled transparently +though, so the application doesn't have to care about that, unless the application provides a virtual keyboard itself. + +The virtual keyboard is placed on top of the application that requires text input, reducing the already limited screen +space even further. While there are split keyboards, floating keyboards, and more, operating systems always treat the +virtual keyboard as a single rectangle overlaying the application window. + +The way Slint exposes this is by these four properties defining a rectangle on the element: + +* +* +* +* + +Slint calls on the operating system to open and hide the virtual keyboard transparently when focusing a text input element. +The operating system decides whether to actually show it, which depends on system settings and whether a hardware keyboard +is detected. This might also change at runtime, for example if the user attaches a hardware keyboard while the virtual +keyboard is visible (in this case, the operating system might hide the virtual keyboard by itself). In any case, if there +is a non-floating virtual keyboard visible, Slint exposes this to the application. + +You can detect if the keyboard is shown by checking whether `virtual-keyboard-width * virtual-keyboard-height` is +greater than 0. + +Some virtual keyboards are translucent, which means that the area below the keyboard can be visible to some extend. So, +the application can display basic visual elements like a solid color there to let the keyboard appear to be integrated +into the visual style. + +Usually, applications don't have to use these properties, due to the behavior explained in the next section. + +:::note[Note] +The way the virtual keyboard overlay is defined differs between Android and iOS. Android defines an inset of the +window (just like the safe area definition above) while iOS supplies a rectangle. Slint unifies this to behave the same +on both platforms, but since these are not mathematically equivalent, there might be certain edge cases with custom +virtual keyboards that might not be handled correctly. It is expected that most keyboards just take up a section of +the bottom of the screen. +::: + +### Keeping the Editing Area Visible + +A common issue is that the text field the user wants to edit ends up below the virtual keyboard, making it invisible. +Slint can automatically handle this by scrolling, but the application has to be structured in a certain way for this to +work. + +When the keyboard is shown, the element currently in focus tries to stay visible. It does that by searching for a +scrollable area () in its parent element chain (up to the window). If it finds one, that area is +instructed to scroll in a way that it doesn't overlap the keyboard with the minimal offset possible. The bounds check +of the scroll area is reduced by the overlap with the keyboard, which means that the area can be scrolled further than +normal. This overscroll is automatically fixed when the keyboard is hidden again. + +So to summarize, if you want to keep a text field in view while the virtual keyboard is shown, put it inside a scroll +area like this: + +```slint +import { LineEdit, ScrollView } from "std-widgets.slint"; +export component MyView { + ScrollView { + mouse-drag-pan-enabled: true; + + VerticalLayout { + label := Text { + text: "Text input"; + horizontal-alignment: left; + overflow: elide; + } + + LineEdit { + placeholder-text: "Write your text"; + accessible-label: label.text; + } + } + } +} +``` + +As you can see, the doesn't need to be the direct parent of the . +Note that having multiple nested `ScrollView`s is not supported. + +## Application Layout Considerations + +While stylus and mouse input can be pixel-accurate, touch input is not, especially with capacitive touch screens. So, +touch-ready applications have to take care to make interactive areas as large as possible and there has to be +enough spacing between touch areas. Also, certain parts of the screen are more easily accessible with the thumb of +the hand that holds the device than others. + +Slint is not able to provide any help with this aspect, so you as the application developers have to keep this in +mind, especially while developing using a device simulator or in a UI design application like Figma. + +We highly recommend reading Apple's +[Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/) and Google's +[Design for Android](https://developer.android.com/design/ui) page. diff --git a/docs/astro/src/content/docs/guide/platforms/ios.mdx b/docs/astro/src/content/docs/guide/platforms/mobile/ios.mdx similarity index 96% rename from docs/astro/src/content/docs/guide/platforms/ios.mdx rename to docs/astro/src/content/docs/guide/platforms/mobile/ios.mdx index 2838f335715..ce19579894d 100644 --- a/docs/astro/src/content/docs/guide/platforms/ios.mdx +++ b/docs/astro/src/content/docs/guide/platforms/mobile/ios.mdx @@ -75,7 +75,7 @@ The shell script is invoked with the name of the binary that cargo produces. Upd 2. In a new file called `build_for_ios_with_cargo.bash`, paste the following script code: -import scriptContent from './../../../../../../../scripts/build_for_ios_with_cargo.bash?raw' +import scriptContent from './../../../../../../../../scripts/build_for_ios_with_cargo.bash?raw' diff --git a/docs/astro/src/content/docs/reference/window/window.mdx b/docs/astro/src/content/docs/reference/window/window.mdx index 480cf2352e1..ac1271f7550 100644 --- a/docs/astro/src/content/docs/reference/window/window.mdx +++ b/docs/astro/src/content/docs/reference/window/window.mdx @@ -71,22 +71,22 @@ The window title that is shown in the title bar. ### safe-area-inset-top -Some devices, such as mobile phones, allow programs to overlap the system UI. A few examples for this are the notch on iPhones, the window buttons on macOS on windows that extend their content over the titlebar and the system bar on Android. This property exposes the amount of space at the top of the window that can be drawn to but where no interactive elements should be placed. +Some devices, such as mobile phones, allow programs to overlap the system UI. A few examples for this are the notch on iPhones, the window buttons on macOS on windows that extend their content over the titlebar and the system bar on Android. This property exposes the amount of space at the top of the window that can be drawn to but where no interactive elements should be placed. On most devices, this is 0. ### safe-area-inset-bottom -Some devices, such as mobile phones, allow programs to overlap the system UI. A few examples for this are the notch on iPhones, the window buttons on macOS on windows that extend their content over the titlebar and the system bar on Android. This property exposes the amount of space at the bottom of the window that can be drawn to but where no interactive elements should be placed. +Some devices, such as mobile phones, allow programs to overlap the system UI. A few examples for this are the notch on iPhones, the window buttons on macOS on windows that extend their content over the titlebar and the system bar on Android. This property exposes the amount of space at the bottom of the window that can be drawn to but where no interactive elements should be placed. On most devices, this is 0. ### safe-area-inset-left -Some devices, such as mobile phones, allow programs to overlap the system UI. A few examples for this are the notch on iPhones, the window buttons on macOS on windows that extend their content over the titlebar and the system bar on Android. This property exposes the amount of space at the left of the window that can be drawn to but where no interactive elements should be placed. +Some devices, such as mobile phones, allow programs to overlap the system UI. A few examples for this are the notch on iPhones, the window buttons on macOS on windows that extend their content over the titlebar and the system bar on Android. This property exposes the amount of space at the left of the window that can be drawn to but where no interactive elements should be placed. On most devices, this is 0. ### safe-area-inset-right -Some devices, such as mobile phones, allow programs to overlap the system UI. A few examples for this are the notch on iPhones, the window buttons on macOS on windows that extend their content over the titlebar and the system bar on Android. This property exposes the amount of space at the right of the window that can be drawn to but where no interactive elements should be placed. +Some devices, such as mobile phones, allow programs to overlap the system UI. A few examples for this are the notch on iPhones, the window buttons on macOS on windows that extend their content over the titlebar and the system bar on Android. This property exposes the amount of space at the right of the window that can be drawn to but where no interactive elements should be placed. On most devices, this is 0. ### virtual-keyboard-x diff --git a/docs/astro/writing-style-guide.md b/docs/astro/writing-style-guide.md index c5863200284..20251beba87 100644 --- a/docs/astro/writing-style-guide.md +++ b/docs/astro/writing-style-guide.md @@ -59,3 +59,5 @@ The dev-platform tabs should be in the following order: - Windows - macOS - Linux +- Android +- iOS \ No newline at end of file diff --git a/internal/core-macros/link-data.json b/internal/core-macros/link-data.json index 3b16b8ed215..b547823825a 100644 --- a/internal/core-macros/link-data.json +++ b/internal/core-macros/link-data.json @@ -149,6 +149,9 @@ "ScrollView": { "href": "reference/std-widgets/views/scrollview/" }, + "Flickable": { + "href": "reference/gestures/flickable/" + }, "StandardButton": { "href": "reference/std-widgets/basic-widgets/standardbutton/" }, @@ -188,6 +191,30 @@ "Window": { "href": "reference/window/window/" }, + "Window.safe-area-inset-top": { + "href": "reference/window/window/#safe-area-inset-top" + }, + "Window.safe-area-inset-bottom": { + "href": "reference/window/window/#safe-area-inset-bottom" + }, + "Window.safe-area-inset-left": { + "href": "reference/window/window/#safe-area-inset-left" + }, + "Window.safe-area-inset-right": { + "href": "reference/window/window/#safe-area-inset-right" + }, + "Window.virtual-keyboard-x": { + "href": "reference/window/window/#virtual-keyboard-x" + }, + "Window.virtual-keyboard-y": { + "href": "reference/window/window/#virtual-keyboard-y" + }, + "Window.virtual-keyboard-width": { + "href": "reference/window/window/#virtual-keyboard-width" + }, + "Window.virtual-keyboard-height": { + "href": "reference/window/window/#virtual-keyboard-height" + }, "WinitBackend": { "href": "guide/backends-and-renderers/backend_winit/" }, @@ -212,4 +239,4 @@ "index": { "href": "" } -} +} \ No newline at end of file diff --git a/tests/doctests/build.rs b/tests/doctests/build.rs index efe3047e522..942a515d1e6 100644 --- a/tests/doctests/build.rs +++ b/tests/doctests/build.rs @@ -88,6 +88,7 @@ fn main() -> Result<(), Box> { tests_file.flush()?; + println!("cargo:rerun-if-changed=../../docs/astro/astro.config.mjs"); // This file is changed when new docs are added println!("cargo:rustc-env=TEST_FUNCTIONS={}", tests_file_path.to_string_lossy()); println!("cargo:rustc-env=SLINT_ENABLE_EXPERIMENTAL_FEATURES=1");