Add more specialized "Pointers" Event. (pen ,touch , mouse)

[xmaxrayx]

Is your feature request related to a problem? Please describe.

Hi, I found this framework use pointers (mouse , touch , pen) as same thing Event source and I didn't like this approach because when you designed UI will need adapted to diff inputs.

• Example 1 : touch input may involve 2 button one of them is fake button and larger size than the not-fake button( act as hit box ) so you can press it more easy once the click made by touch.

• Example 2: you may make the app change the app once detected a pen input for less keyboard shortcut.

so this why it's better to have more than Generic pointers that apply to all, you make it auto if the user didnt sub to special input event.

Describe the solution you'd like

add Pen-Pointers , touch-pressed

Describe alternatives you've considered

No response

Additional context

No response

[thevortexcloud]

Example 1 : touch input may involve 2 button one of them is fake button and larger size than the not-fake button( act as hit box ) so you can press it more easy once the click made by touch.

I don't think I have ever used a UI framework that works like this. Is this a common thing? Anyway, I feel like you could solve this by just making bigger buttons?

you may make the app change the app once detected a pen input for less keyboard shortcut.

This could be useful, but right now it would be hard to implement. Avalonia's style system needs more work for full responsive design. EG

#16846
#16962

Anyway, Avalonia does already have a way to tell what the current pointer type is.

Avalonia/src/Avalonia.Base/Input/IPointer.cs

Lines 55 to 70 in 7087595

	public enum PointerType
	{
	/// <summary>
	/// The input device is a mouse.
	/// </summary>
	Mouse,
	/// <summary>
	/// The input device is a touch.
	/// </summary>
	Touch,
	/// <summary>
	/// The input device is a pen.
	/// </summary>
	Pen

Avalonia/src/Avalonia.Base/Input/PointerEventArgs.cs

Lines 51 to 54 in 7087595

	/// <summary>
	/// Gets specific pointer generated by input device.
	/// </summary>
	public IPointer Pointer { get; }

However in most cases people don't care what caused the event. It also sounds like you are using code behind? If you are using MVVM you typically use Command for buttons, which intentionally hides what caused the command to be executed in the first place.

[xmaxrayx]

I don't think I have ever used a UI framework that works like this. Is this a common thing? Anyway, I feel like you could solve this by just making bigger buttons?

it's more used with phones keyboard app and more need when you going design in small UI.

Anyway, Avalonia does already have a way to tell what the current pointer type is.

sadly not every control have PointerEventArgs you need window_pointer with out-scope variable or warp your control around fake empty grid so you can use PointerEventArgs which make the code messy and not fun to look at it.

example : Buttons, dont have PointerEventArgs e

I dont't use command i dont like them bc as u said they hide stuff what cause them.

[thevortexcloud]

example : Buttons, dont have PointerEventArgs e

Actually they do. Button's (indirectly) inherit from InputElement, as well as most other controls in Avalonia

Avalonia/src/Avalonia.Base/Input/InputElement.cs

Lines 153 to 160 in fa19076

	/// <summary>
	/// Defines the <see cref="PointerPressed"/> event.
	/// </summary>
	public static readonly RoutedEvent<PointerPressedEventArgs> PointerPressedEvent =
	RoutedEvent.Register<InputElement, PointerPressedEventArgs>(
	nameof(PointerPressed),
	RoutingStrategies.Tunnel | RoutingStrategies.Bubble);

Which has the pressed event. Although it does work a bit differently from the Click event that the button itself has.

https://docs.avaloniaui.net/docs/concepts/input/pointer

[TomEdwardsEnscape]

I think the idea here is an application which supports multiple interaction devices simultaneously, and controls behave differently depending on which one is currently interacting with them. So a button is the normal size for the mouse, but has an enlarged hit region which is only applied when PointerType == Touch. That would be tricky to pull off, but could in principle work.

That specific issue isn't actually related to pointer events, but to the hit testing which occurs before the event is raised. As far as I can see the hit testing system only uses a raw Point with no information about the reason why the hit test was requested.

[xmaxrayx]

yeah indeed with current Avalonia system you need like code more and warp around window_keydown , Window_pointerPressed which not fun and messy approach.

or you can use WinAPI DLL and hock they mouse/key status but whats the point when Avalonia meant for cross platforms.

[thevortexcloud]

That would be tricky to pull off, but could in principle work.

I would say so, it would basically require rearranging the entire UI to avoid hit boxes overlapping each other, and at that point you may as well just use a larger button.

[maxkatz6]

As mentioned above, we went with Pointer*** APIs providing a single common API for any pointer-like input event. Ensuring developers don't need to write more code for each new input app needs to support. And even more importantly - supporting these input types without developer needing to care about them for common cases.
Adding a specialized event, like MouseDown or TouchPressed will make a new beginner mistake of handling one of these events, ignoring other inputs.

I didn't like this approach because when you designed UI will need adapted to diff inputs.

You can do that. From pointer arguments you can get input information and pointer type (mouse, pen or touch).
You also can group your inputs by Pointer.Id, in case if you want to handle something like multi-touch input, where each finger needs to be tracked individually.

[xmaxrayx]

but what you can do with controls that don't support Pointers e other than using fake grid or window_loaded ? wish at least we have pointer.get() and keyboard.isKeyDown(key.c)