Allow users to configure maximum size of chords

[alice-i-cecile]

No description provided.

[alice-i-cecile]

Another const generic let's go.

[TimJentzsch]

What exactly do you envision here? Should the UserInput struct have the const generic which is then passed to the chord case instead of the 8?

Should the chord method stay as an iterator? What happens if the iterator has more items than are allowed?

Relevant code for future reference:

leafwing-input-manager/src/user_input.rs

Lines 21 to 25 in ef037f9

	/// A combination of buttons, pressed simultaneously
	///
	/// Up to 8 (!!) buttons can be chorded together at once.
	/// Chords are considered to belong to all of the [InputMode]s of their constituent buttons.
	Chord(PetitSet<InputKind, 8>),

leafwing-input-manager/src/user_input.rs

Lines 31 to 48 in ef037f9

	/// Creates a [`UserInput::Chord`] from an iterator of [`InputKind`]s
	///
	/// If `inputs` has a length of 1, a [`UserInput::Single`] variant will be returned instead.
	pub fn chord(inputs: impl IntoIterator<Item = impl Into<InputKind>>) -> Self {
	// We can't just check the length unless we add an ExactSizeIterator bound :(
	let mut length: u8 = 0;
	let mut set: PetitSet<InputKind, 8> = PetitSet::default();
	for button in inputs {
	length += 1;
	set.insert(button.into());
	}
	match length {
	1 => UserInput::Single(set.into_iter().next().unwrap()),
	_ => UserInput::Chord(set),
	}
	}

[alice-i-cecile]

Should the UserInput struct have the const generic which is then passed to the chord case instead of the 8?

This is the idea; but set a default value of 8 to avoid ergonomics regression.

Should the chord method stay as an iterator? What happens if the iterator has more items than are allowed?

This is the same situation as we have now. We should probably have a fallible version that returns a result for dynamic keybinding use cases.