~egonelbre


#572 Fwd: Detecting mouse wheel a month ago

Comment by ~egonelbre on ~eliasnaur/gio

Actually, there already exists layout.Constraints that solves a similar problem. However, that seems to assume that the ranges are >= 0.

As for whether to use ScrollX / ScrollY -- I don't have a strong opinion. However, it might be easier within the gio internal codebase to have a single value rather than two different ones. Similarly the scroll result in pointer.Event is returned as f32.Point -- so I kind of would expect the Scroll to be a single field at least. e.g.

   Scroll ScrollRanges
}
type ScrollRanges { X, Y ScrollRange }
type ScrollRange { Min, Max int }

Though, it does introduce some extra types when declaring the filters. The separate fields might be a good compromise.

#572 Fwd: Detecting mouse wheel a month ago

on ~eliasnaur/gio

~egonelbre is right, of course. The collapsing behaviour of Union suggests to me that scroll ranges should be independent. Say:

package pointer

type Filter struct {
    ....
    ScrollX ScrollRange
    ScrollY ScrollRange
}

type ScrollRange struct {
    Min, Max int
}

WDYT?

#572 Fwd: Detecting mouse wheel a month ago

Comment by ~egonelbre on ~eliasnaur/gio

I think I've figured out the issue, the scrollRange calculations are using Rectangle.Union (one example https://git.sr.ht/~eliasnaur/gio/tree/main/item/io/input/pointer.go#L300)

Rectangle.Union is implemented as:

func (r Rectangle) Union(s Rectangle) Rectangle {
if r.Empty() { return s }
if s.Empty() { return r }

The fix is to replace image.Rectangle with a different type, e.g. ScrollRange, that implements Union without collapsing the ranges when one of the dimensions is empty.

#557 update typesetting usage 2 months ago

Comment by ~egonelbre on ~eliasnaur/gio

Without seeing go.mod it's difficult to say anything specific, but usually, removing dependency the lines from go.mod (i.e. everything except module and go version declaration) and running go mod tidy makes things work again. Alternatively, revert to an earlier working go.mod and then only update gio with go get gioui.org@latest

#564 not enough arguments in call to s.fontMap.AddFace 3 months ago

Comment by ~egonelbre on ~eliasnaur/gio

Generally, use the same version of github.com/go-test/typesetting as specified in gio/go.mod (unless you have a good reason not to).

You most likely ended up in this situation when updating with go get -u gioui.org@latest. In general avoid -u when updating, because it also bumps unstable packages to the latest major version, which has a different meaning from a stable version. In unstable versioning it is often used to indicate a breaking change. See more details in https://github.com/golang/go/issues/64864.

#561 gio 3 months ago

on ~eliasnaur/gio

It Worked!

THX

Am Mi., 7. Feb. 2024 um 14:07 Uhr schrieb ~egonelbre outgoing@sr.ht:

If you use the main branch then it works:

go run gioui.org/example/component@main

I guess there hasn't been a patch release yet.

  • Egon

On Wed, Feb 7, 2024 at 2:48 PM ~Stoffel Winiman outgoing@sr.ht wrote:

Hi GIO,

The component example do not work completely. The ModalNav does not change the pages.

I tried to debug, but I did not find the error, except the click would not be processed.

https://pkg.go.dev/gioui.org/example@v0.4.0/component

best regard, Stefan Weinmann

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/561

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/561#event-294960

-- Beste Grüße Stefan Weinmann

#561 gio 3 months ago

Comment by ~egonelbre on ~eliasnaur/gio

If you use the main branch then it works:

go run gioui.org/example/component@main

I guess there hasn't been a patch release yet.

  • Egon

On Wed, Feb 7, 2024 at 2:48 PM ~Stoffel Winiman outgoing@sr.ht wrote:

Hi GIO,

The component example do not work completely. The ModalNav does not change the pages.

I tried to debug, but I did not find the error, except the click would not be processed.

https://pkg.go.dev/gioui.org/example@v0.4.0/component

best regard, Stefan Weinmann

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/561

#555 Overhaul of package app 5 months ago

on ~eliasnaur/gio

I share ~egonelbre's concern that StageEvent filled a useful niche. I know one use-case for it was detecting focus loss in order to close the window. This was for an application launcher, which it makes sense to just close if the user clicks away from it. Another use case is wanting to play sound only when your window has focus. It is not clear to me how to tell the difference between "my window has focus" and "my window isn't being invalidated because there are no input events right now."

I also don't see how key.FocusEvent covers window focus tracking entirely. If I install a root-level key handler, it will get a focus event each time the focus changes between widgets, and I suppose it also gets one when the window loses focus, but I don't see any fields on key.FocusEvent that would differentiate between "focus transferred to another widget" and "focus transferred to another window."

Am I missing some invariants or side-channels that make the above issues moot?

#555 Overhaul of package app 5 months ago

on ~eliasnaur/gio

~egonelbre: note that we have the app.Minimized WindowMode already. More importantly, platforms such as Wayland won't ever tell you whether a window is minimized, so your use-case seems better triggered by, say, the loss of window focus.

#555 Overhaul of package app 5 months ago

Comment by ~egonelbre on ~eliasnaur/gio

I'm not quite convinced that you can easily and reliably detect StageEvent-s from the presence of FrameEvents. e.g. You have a separate audio goroutine that should be paused when the app is minimized, then it's not obvious whether the app isn't getting events due to not needing to render anything or due to being minimized.