Skip to content

Conversation

hunger
Copy link
Member

@hunger hunger commented Jul 11, 2025

... which is lowered to a string for now.

Add a new type keyboard-shortcut, that is parsed from @keys(shift + control + a) and gets lowered to a string in Rust and C++ and the interpreter for now.

| Type::Image
| Type::Easing
| Type::Array(_)
| Type::KeyboardShortcut => {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tired to return a String that contains the stringified definition, but that causes infinite recursion... I need to check out why that happens in detail.

/// @keys(ctrl +shift + alt+meta+a)
/// @keys(control +shift + alt+meta+a)
/// ```
fn parse_keys(p: &mut impl Parser) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should allow , separated lists of elements.

The logic to decide on the actual key being uses is also a bit simplistic: We should (in addition?) accept the keys from our Keys namespace. But So I should probably let all unknown identifiers through here and match them to the Keys namespace (or the single character).

@hunger hunger force-pushed the tobias/keyboard-shortcut branch from 78e44e2 to 7b8e4d0 Compare July 11, 2025 17:41
Copy link
Member

@ogoffart ogoffart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry i haven't took the time to review this before my vacations.
I've had a quick look at it and didn't see anything wrong.

I'm thinking we shouldn't merge this to master (stabilize) unless this is used. Would it be easy to gate this as an experimental feature? (the new type and the @keys)

}

#[derive(Clone, Debug, Default)]
pub struct KeyboardModifiers {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't we already have such a type somewhere else?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do. But I can not get to it from here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do have this type in i_slint_core, but that is not listed in the compiler's Cargo.toml. I did not want to add it, as there is probably a reason for not having that.

@hunger
Copy link
Member Author

hunger commented Jul 21, 2025

I wanted to keep this unmerged for the time being and build on top of this PR.

@hunger hunger force-pushed the tobias/keyboard-shortcut branch from 7b8e4d0 to 55ab234 Compare July 28, 2025 16:48
@hunger
Copy link
Member Author

hunger commented Jul 28, 2025

Newest version now accepts keys from the Keys namespace. To match up with what is defined in there, I also renamed the modifiers to start with uppercase characters. I have ignored the right-side variant of the modifier keys for now.

hunger added 3 commits August 18, 2025 07:40
... which is lowered to a string for now.
Language Suppord:
 * Rust: :check:
 * C++: :fail:
 * Python: ❓
 * JS: ❓
@hunger hunger force-pushed the tobias/keyboard-shortcut branch from 443c344 to 116e72f Compare August 19, 2025 07:31
@hunger
Copy link
Member Author

hunger commented Aug 19, 2025

A bit of progress was made:

  • Old branch: Rebased the entire thing on top of current master
  • New commit: Printing was fixed to match inputs better (should be squashed)
  • New commit: Add a KeyboardShortcut struct to the builtin structs and expose that to Slint
    • Rust works
    • C++ still converts to a string somewhere and fails, should be easy to fix though
    • Python and JS is untested so far

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants