proxmox/proxmox-yew-widget-toolkit
Watch
1
0
Fork
You've already forked proxmox-yew-widget-toolkit
 0
mirror of https://git.proxmox.com/git/ui/proxmox-yew-widget-toolkit.git synced 2026-08-26 23:51:00 +00:00
Code Issues Projects Releases Packages Wiki Activity
No description
2,047 commits 1 branch 0 tags 4.2 MiB
  • Rust 99.8%
  • Makefile 0.1%
Find a file
Exact
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Dietmar Maurer 15a3ad6a10 dropdown: derive picker close from explicit picks, not timing 
A value change arriving while the picker is open can be an explicit
pick (close the picker) or the picker mirroring a keystroke of the
user typing into an editable field (keep it open for further
filtering). The dropdown inferred the difference from timing: a
one-shot flag armed by each keystroke and cleared by the next value
change. Pickers that do not mirror keystrokes broke that inference:
the flag stayed armed and absorbed the actual pick, so the first
click on a SearchDropdown result after typing did nothing, and the
editable DateField lost the first calendar pick after typing the
same way.

The ambiguity only exists because the grid picker reported
selections by observing the shared selection state, which cannot
tell a user's click from the owning field mirroring typed input.
Report picks from direct table interaction instead (row click,
Enter, Space) and drop the guard: a value change from the picker now
always means an explicit pick, and typing never closes the picker.

This also fixes picking the already-selected entry: the selection
state does not change in that case, so such a click or Enter never
closed the picker before.

GridPicker::on_select now fires only for direct user interaction;
all known users wire it to the dropdown controller, where this is
the intended meaning.

Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
2026-08-11 09:20:12 +02:00
.cargo add .cargo/config.toml to build from debian packages 2024-08-12 10:12:54 +02:00
debian bump version to 0.8.16 2026-08-05 17:58:15 +02:00
pwt-macros macros: bump version to 0.5.3 2026-06-29 02:59:32 +02:00
src dropdown: derive picker close from explicit picks, not timing 2026-08-11 09:20:12 +02:00
.gitignore gitignore build and target 2023-02-19 11:51:53 +01:00
Cargo.toml bump version to 0.8.16 2026-08-05 17:58:15 +02:00
js-helper-module.js js-helper: guard client_to_svg_coords against a missing CTM 2026-05-23 22:07:47 +02:00
LICENSE-APACHE LICENSE change: MIT or APACHE2 (same as yew) 2023-01-10 18:30:37 +01:00
LICENSE-MIT LICENSE change: MIT or APACHE2 (same as yew) 2023-01-10 18:30:37 +01:00
Makefile bump version to 0.4.8 2025-01-27 14:53:25 +01:00
README.md readme: fix example URL and provide git clone one 2025-08-02 21:22:06 +02:00
rustfmt.toml rustfmt: use 2024 style edition 2026-05-27 01:09:48 +02:00
Whitepaper.md whitepaper: add missing sections and update conclusion 2026-04-10 17:36:28 +02:00

README.md

Motivation

The motivation for writing this toolkit was:

  1. Problems with the currently used JavaScript based framework
  2. We want to reduce the number of programming languages

The company writes more and more code in rust, so 'yew' was a natural choice. Most code can be written in rust, but it is still possible to use JavaScript. This allows to use existing JavaScript libraries when necessary.

The Whitepaper contains more details on this.

Usage

We provide a separate repository with usage examples:

https://git.proxmox.com/?p=ui/proxmox-yew-widget-toolkit-examples.git;a=tree

git clone git://git.proxmox.com/git/ui/proxmox-yew-widget-toolkit-examples.git

Contributions

All contributions to this project must accept the Developer Certificate of Origin (DCO) https://developercertificate.org/

See our Developer Documentations for how to communicate with other developers and for how to sent patches https://pve.proxmox.com/wiki/Developer_Documentation

I18N

All translatable strings are marked using the "tr!" macro.

Extract gettext messages with the "xtr" binary, which is part of the "tr" crate.

See the demo in the examples crate on how to use this.

Notes

We try to use the builder pattern instead of the html macro.

Conventions:

  • The Yew Component is prefixed with "Pwt" (i.e. "PwtColumn")
  • Corresponding Component Properties without prefix (i.e. "Column")
  • Builder is implemented on the Component Properties.
  • Component Properties implements Into<Html>.

Focus traversal

Focus handling should be like:

https://developer.mozilla.org/en-US/docs/Web/Accessibility/Keyboard-navigable_JavaScript_widgets

Dialog

We use the new html <dialog> tag (mainly to simplify focus handling).

This should work in major browsers now (2022). Anyways, a polyfill is also available:

https://github.com/GoogleChrome/dialog-polyfill

You can enable it manually in older versions of firefox in "about:config" using the dom.dialog_element.enabled setting.

Debugging

The simplest way to debug is using 'printf' debugging using the standard log macros log::{info,warning,error} in the code itself.

Another way is to use the DWARF info from wasm in the browser (chrome/chromium only):

  • compile wasm file but keep debug info:
    • trunk: <link data-trunk rel="rust" data-keep-debug data-no-demangle> in index.html
    • others: --keep-debug in wasm-bindgen
  • install debugging extension in chrome:
  • open page with wasm with DWARF info
    • there should be a message in the console like: [C/C++ DevTools Support (DWARF)] Loading debug symbols for ...
  • debugger should show a file:// entry for rust files on disk
    • if the paths match with your local install, nothing else is to be done
    • otherwise, use the extension options to map the source paths correctly