on_hover receives absolute mouse coordinates; every other mouse callback receives relative ones

[jaysonsantos]

Summary

on_hover is the only mouse callback that receives window-absolute coordinates. on_click, on_any_click, on_mouse_move and on_mouse_up all receive coordinates relative to the widget's own shape.

Because both hand you an Event with mouse_x / mouse_y, nothing signals the difference. Hit-testing code written against one and reused for the other silently reads the wrong position.

Where it comes from

The relative path goes through execute_mouse_callback in event_traversal.v:61, which converts before dispatch:

// Make mouse coordinates relative to layout.shape
mut ev := event_relative_to(layout.shape, e)
callback(layout, mut ev, mut w)

on_hover is dispatched from layout_hover in layout.v:145 instead, which builds a synthetic event straight from the context and never converts:

mut ev := Event{
    ...
    mouse_x: ctx.mouse_pos_x
    mouse_y: ctx.mouse_pos_y
    ...
}
on_hover := layout.shape.events.on_hover

Effect

Inside a canvas that hit-tests its own content, the two handlers need different arithmetic for the same pointer position:

on_any_click: fn (l &gui.Layout, mut e gui.Event, mut w gui.Window) {
    hit(e.mouse_x, e.mouse_y)                            // already relative
}
on_hover: fn (mut l gui.Layout, mut e gui.Event, mut w gui.Window) {
    hit(e.mouse_x - l.shape.x, e.mouse_y - l.shape.y)    // must subtract
}

Using the same expression in both compiles, runs, and quietly misses every target in one of them.

Suggestion

Either convert in layout_hover the way execute_mouse_callback does, or document the difference on on_hover. Converting looks like the smaller surprise, though it would change behaviour for anyone already compensating.

Version: gui at e699bcf, V 0.5.2, macOS arm64.