North Carolina
Interested in Linux, decentralization, cryptography, golang/rust/c, and communication.
I spend most of my free time on:
If you get value out of my work, please consider sponsoring me on Liberapay or GitHub.
From Chris Waldon to ~eliasnaur/gio-patches
> > > 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?
From Chris Waldon to ~eliasnaur/gio-patches
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]
From Chris Waldon to ~eliasnaur/gio-patches
Thank you for fixing these Dominik! I finally had a chance to look through them in depth. Cheers, Chris
From Chris Waldon to ~eliasnaur/gio
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
From Chris Waldon to ~eliasnaur/gio
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
From Chris Waldon to ~eliasnaur/gio-patches
> > - 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.
From Chris Waldon to ~eliasnaur/gio
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:
From Chris Waldon to ~eliasnaur/gio-patches
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]
From Chris Waldon to ~eliasnaur/gio-patches
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]
From Chris Waldon to ~gioverse/chat
> @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!