> > > This change indicates that returning true from IndicatorHovered seems
> > > logical.
> > >
> >
> > It's not uncommon for scrollbar indicators to render differently for
> > hovered and clicked. I just went with the easy option here and render
> > them identically. I wouldn't be surprised if you'd want to change this
> > in the future.
> >
> > However, on second thought, I'm not happy with "Dragging" and its
> > implementation. The indicator can be in a state where it's being clicked
> > but not yet being dragged. I.e. it's "active" but hasn't moved yet. For
> > styling, we're really interested in clicked, regardless of dragging.
> > What do you think?

This commit updates the way that we change cursors so that the
hotspot of the cursor is properly set to surface-local coordinates.
The previous raw hotspot coordinates are relative to the cursor
image buffer data, and do not take the buffer's scaling factor
into account.

Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
---
 app/os_wayland.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/os_wayland.go b/app/os_wayland.go
index dc5da440..69c5ced4 100644
--- a/app/os_wayland.go
[message trimmed]

Thank you for fixing these Dominik! I finally had a chance to look
through them in depth.

Cheers,
Chris

On Tue, Jun 28, 2022 at 5:24 PM Dominik Honnef <dominik@honnef.co> wrote:
>
> Chris Waldon <christopher.waldon.dev@gmail.com> writes:
>
> > Hey Dominik,
> >
> >> let me first describe my current scenario: I am visualizing a trace,
> >> which results in thousands of spans. I'd like to know which, if
> >> any, span a user has clicked on, and act on that. The spans
> >> themselves don't act as independent widgets, and are controlled by a
> >> timeline widget.
> >>
> >> The naive solution would be to record a pointer.InputOp per span.
> >> But to be able to differentiate the spans, I would need one tag

Hey Dominik,

> let me first describe my current scenario: I am visualizing a trace,
> which results in thousands of spans. I'd like to know which, if
> any, span a user has clicked on, and act on that. The spans
> themselves don't act as independent widgets, and are controlled by a
> timeline widget.
>
> The naive solution would be to record a pointer.InputOp per span.
> But to be able to differentiate the spans, I would need one tag
> per. To check which span has been clicked, then, I would need to
> check each and every tag, doing O(n) work. This seems like a waste of
> resources, considering Gio already knows what I clicked and could tell
> me in O(1). We would also have to maintain additional state - the list

> > -       w.cursor.theme = C.wl_cursor_theme_load(nil, C.int(32*w.scale), d.shm)
> > +       cursorTheme := C.CString(os.Getenv("XCURSOR_THEME"))
>
> Added a C.free.

Thanks! Sorry for missing that.

Hi James,

> - We notice that things like spell-check do not work on iOS and even Android

Spell-check is a pretty advanced feature. It requires communicating
with some platform text libraries to check the contents of a text
buffer against known dictionaries, gathering a list of candidates that
unknown words could have been meant to be, and presenting an interface
for choosing (or not) to replace mis-spelled words with one of those
candidates. Right now, Gio does not attempt any of this, though
naturally we'd like to have such features available. I don't think we
even have a design in mind for how this should work, however, I can
offer the minimum-effort path forward:

This commit adds support for the commonly-used XCURSOR_THEME and
XCURSOR_SIZE environment variables. Wayland lacks a protocol-level
way to standardize cursor size right now, but these variables are
used consistently by many applications and compositors. Many users
(including me) will find that their environment is already configuring
these for them, and will get consistent cursor sizing for free.

I explored a lot of ways to tackle this, but it looks like nobody has
ever gotten around to implementing the cursor theme protocol discussed
here:

https://wayland-devel.freedesktop.narkive.com/VuMSOO55/possible-wayland-extension-to-publish-mouse-pointer-size

Given that it doesn't seem to be resolved anytime soon, supporting a
[message trimmed]

This commit scales both the loaded cursor theme and the cursor
surface appropriately so that the cursor image is not blurry on
HiDPI screens.

References: https://todo.sr.ht/~eliasnaur/gio/382
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
---
 app/os_wayland.go | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/app/os_wayland.go b/app/os_wayland.go
index aa255bd9..6ad40974 100644
--- a/app/os_wayland.go
+++ b/app/os_wayland.go
[message trimmed]

> @Chris You raise good points, and I ultimately I agree with your conclusion.
> Let's leave it then! Though I would still like to drop the "And" part.
> ;)

Cool, I've pushed the results of this discussion. Thanks all!