app,io/system: [API] add StageInactive when window is not in focus

[inkeliz]

Now, Gio will notify when window focus changes.

Signed-off-by: Inkeliz inkeliz@inkeliz.com

[inkeliz]

Currently, the behavior of "focus" is defined by the OS, which doesn't match very well. On Windows, the "focus" is lost when some children is focused, on MacOS it's not, but there's another event for that case. However, the FocusEvent can be improved once Gio have better support for children windows.

[eliasnaur]

Everywhere you send a system.FocusEvent when a key.FocusEvent is also sent. Why is key.FocusEvent not enough?

[whereswaldon]

key.FocusEvent is going to be consumed by the foremost key handler, which may be deeply nested within application layout code. Wanting to change a window behavior based on the window focus state is a much higher-level concern. One user asked for this focus detection feature in order to build a dmenu-esque application launcher. If the window loses focus, they want to close the window. Doing that by interrogating the state of every widget to see if any of them are focused doesn't seem like the right design.

[inkeliz]

I don't use key.FocusEvent because of the reason mentioned by @whereswaldon. Also, the FocusEvent can work differently from key.FocusEvent.

I force-push to make the behavior differently. Now, the FocusEvent is only triggered when the window loses focus, instead of the keyboard focus. The word "focus" could be changed to "active", or something else.

[inkeliz]

On Windows, the KILLFOCUS happens when another window have keyboard focus, which might also happens when some child window is in focus. The NCACTIVATE sounds better, since it report when the window decoration should update.

[eliasnaur]

Currently, the behavior of "focus" is defined by the OS, which doesn't match very well. On Windows, the "focus" is lost when some children is focused, on MacOS it's not, but there's another event for that case. However, the FocusEvent can be improved once Gio have better support for children windows.

This difference between macOS and WIndows is fixed by #93, right?

I don't use key.FocusEvent because of the reason mentioned by @whereswaldon. Also, the FocusEvent can work differently from key.FocusEvent.

I force-push to make the behavior differently. Now, the FocusEvent is only triggered when the window loses focus, instead of the keyboard focus. The word "focus" could be changed to "active", or something else.

Thanks for explaining. I agree that it would be useful to know the active state of an app.Window, separate from the focus. However, I'm not sure a separate event is necessary. Why not expand io/system.Stage with a StageInactive and rename StageRunning to StageActive?

[inkeliz]

I initially thought about adding a new Stage, but on https://lists.sr.ht/~eliasnaur/gio/%3C96373f04-28fe-6848-25f4-2d9936aa0522%40gmail.com%3E#%3CCAMAFT9VY22-baCO+OyzM+cGH7ktVU08RvgKQOTrbAtAO91beWg@mail.gmail.com%3E, you mention to add that as a new FocusEventt.

However, I'm not sure how the new Stage will work, because we have some checks: if stage < system.StageRunning:

gio/app/window.go

Lines 828 to 835 in b67bef3

	if e2.Stage < system.StageRunning {
	if w.gpu != nil {
	w.ctx.Lock()
	w.gpu.Release()
	w.gpu = nil
	w.ctx.Unlock()
	}
	}

---

Currently, the Stage is either "Running" or "Inactive":

gio/io/system/system.go

Lines 61 to 67 in b5f12c5

	const (
	// StagePaused is the Stage for inactive Windows.
	// Inactive Windows don't receive FrameEvents.
	StagePaused Stage = iota
	// StateRunning is for active Windows.
	StageRunning
	)

But, in the case of "not in focus" it's both of them, at same time. It's inactive at the perspective of the user, but it's active because it can generate new frames (it still displayed on the screen).

I don't think that it makes sense but maybe we can use 1 << iota +1 and then use StageRunning | StageInactive? So, it's running (gio is generating frames), but it's inactive (the window is not in focus).

[eliasnaur]

I initially thought about adding a new Stage, but on https://lists.sr.ht/~eliasnaur/gio/%3C96373f04-28fe-6848-25f4-2d9936aa0522%40gmail.com%3E#%3CCAMAFT9VY22-baCO+OyzM+cGH7ktVU08RvgKQOTrbAtAO91beWg@mail.gmail.com%3E, you mention to add that as a new FocusEventt.

FocusEvent could work if we can't cram the focused/active state into Stage.

However, I'm not sure how the new Stage will work, because we have some checks: if stage < system.StageRunning:

gio/app/window.go

Lines 828 to 835 in b67bef3

	if e2.Stage < system.StageRunning {
	if w.gpu != nil {
	w.ctx.Lock()
	w.gpu.Release()
	w.gpu = nil
	w.ctx.Unlock()
	}
	}

This check (and similar) should change to e2.Stage == system.StagePaused.

Currently, the Stage is either "Running" or "Inactive":

gio/io/system/system.go

Lines 61 to 67 in b5f12c5

	const (
	// StagePaused is the Stage for inactive Windows.
	// Inactive Windows don't receive FrameEvents.
	StagePaused Stage = iota
	// StateRunning is for active Windows.
	StageRunning
	)

But, in the case of "not in focus" it's both of them, at same time. It's inactive at the perspective of the user, but it's active because it can generate new frames (it still displayed on the screen).

I don't think that it makes sense but maybe we can use 1 << iota +1 and then use StageRunning | StageInactive? So, it's running (gio is generating frames), but it's inactive (the window is not in focus).

Stage was designed to be an integer of increasing "liveness" of the window. So for active, inactive:

 const ( 
 	// StagePaused is the stage for windows that have no on-screen representation. 
 	// Paused Windows don't receive FrameEvents. 
 	StagePaused Stage = iota
        // StageInactive is the stage for windows that are visible, but not active.
        StageInactive
        // Inactive windows receive FrameEvents.
 	// StateRunning is for active and visible Windows.
        // Active windows receive FrameEvents. 
 	StageRunning 
 ) 

[inkeliz]

Sorry for a lot of force pushes, but there's no change between them. That fixed comparison, as you suggest.

[eliasnaur]

Merged, thanks!