`PointerData` ergonomics

[TheRedDeveloper]

Summary

Make pointer interaction detection ergonomic by introducing a cleaner PointerState API inside a dedicated pointer module.

Motivation

This is the current logic to check if the cursor is pressed while hovering:

on_hover(|id, pointer| {
  let is_pressed =
    pointer.state == ply_engine::engine::PointerDataInteractionState::Pressed ||
    pointer.state == ply_engine::engine::PointerDataInteractionState::PressedThisFrame;
  if is_pressed {
    // activate
  }
})

You need:

• Fully qualified paths to internal engine types
• Manual state enumeration
• Knowledge that internal engine:: types are being exposed, which violates the principle that engine internals should not be user-facing

This was pointed out in #55.

Proposed API

New pointer module:

#[derive(Clone, Copy, Debug)]
pub struct PointerData {
    pub position: Vector2,
    pub state: PointerState,
}

#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub enum PointerState {
    #[default]
    Idle,
    PressedThisFrame,
    Pressed,
    ReleasedThisFrame,
}

impl PointerData {
    /// Check if pointer is currently pressed
    pub fn pressed(&self) -> bool {
        matches!(self.state, PointerState::Pressed | PointerState::PressedThisFrame)
    }

    /// Check if pointer is currently released
    pub fn released(&self) -> bool {
        matches!(self.state, PointerState::Idle | PointerState::ReleasedThisFrame)
    }
    
    /// Check if pointer was just pressed this frame
    pub fn just_pressed(&self) -> bool {
        self.state == PointerState::PressedThisFrame
    }

    /// Check if pointer is just released this frame
    pub fn just_released(&self) -> bool {
        self.state == PointerState::ReleasedThisFrame
    }
}

Behavior

• The old engine::PointerData and PointerDataInteractionState types are removed
• The new pointer::PointerData and pointer::PointerState types are used everywhere
• crate::pointer::* is put in the prelude

[SoSeDiK]

(continuation from #55 (comment))

If on_press() accepts a MouseButton it doesn't have any meaning for the other platforms

It does as long as the platform accepts a mouse as an input device.

because not all presses are made by the mouse

Correct. That's expected behavior. The entire scope of this addition would be to provide support for mouse specifically.

Am I supposed to say that pressing the space button is a left-click?

No, pressing Space is pressing Space and should be reported as pressing Space. As mentioned, one of the solutions would be to provide the identifier like miniquad's MouseButton/KeyCode and let the dev handle it.

I understand the point of current "press" logic being a simple multi-platform "click" detection and it can remain being so. The proposed on_press/on_release with a MouseButton overload, if chosen, can be named differently to avoid confusion between the two.
Using MouseButton::Left explicitly should only cover LMB and not anything else. Other inputs are to be handled separately.

Not every pointer is a mouse

Yes, that's the point. The requested feature concerns the mouse and mouse only. Likewise, touch input should have its own system with simple single on_tap, multitouch (using multiple fingers for simultaneous taps), long press (touching an element for N amount of time), swipes, pinch/zoom and other fancies that are specific only to mobile/touchscreen.

Having a simple API to detect mouse right/middle/etc. click does not cause any harm to other use-cases that do not involve a mouse.

---

TL;DR: The interaction system should additionally provide a more granular, device-specific opt-in APIs rather than forcing all input through a lowest-common-denominator abstraction.