The April 2024 newsletter says the StageEvent was removed because it's
redundant:
"To detect whether the window is currently visible. That is covered by
the absence or presence of app.FrameEvents."
Can you elaborate on this? I've instrumented my app to log FrameEvents
and it stops getting them if the UI isn't changing (macOS & Linux X11,
at least). It also doesn't seem to get any notification (aside from
losing focus, if it had it) if it's iconified or "hidden" (e.g. Cmd-H
to "hide" or any other app's cmd-alt-H to "hide others").
-- Larry
On Fri, 19 Apr 2024 at 16:40, Larry Clapp <lclapp.gio@gmail.com> wrote:
>> The April 2024 newsletter says the StageEvent was removed because it's> redundant:>> "To detect whether the window is currently visible. That is covered by> the absence or presence of app.FrameEvents.">> Can you elaborate on this? I've instrumented my app to log FrameEvents> and it stops getting them if the UI isn't changing (macOS & Linux X11,> at least). It also doesn't seem to get any notification (aside from> losing focus, if it had it) if it's iconified or "hidden" (e.g. Cmd-H> to "hide" or any other app's cmd-alt-H to "hide others").>
The idea is that being iconified or otherwise hidden is not a reliable
notification
(e.g. Wayland doesn't report it), so it's more portable to use one of
the options
listed in the newsletter: window focus for "saving state"-like cases, lack of
FrameEvents to control animations and ViewEvent for managing the lifetime
of native resources tied to the window.
Do you have a particular use-case in mind?
Elias
I have to say, I also hate this idea of detecting the ‘absence of FrameEvent’.
It adds a lot of complication to the app main loop, you have to:
- have a separate goroutine with a timer
- reset the timer when there’s a FrameEvent
- trigger the app main loop with w.Invalidate or similar mechanism
Can’t we have Gio do this for us on Wayland, wasm platforms; and pass through
the native visibility events on backends that can support them? I get that
you mostly want to go for the ‘common denominator’ functionality, but it’s very
limiting.
On 19 Apr 2024, at 17:00, Elias Naur wrote:
> On Fri, 19 Apr 2024 at 16:40, Larry Clapp <lclapp.gio@gmail.com> wrote:>>>> The April 2024 newsletter says the StageEvent was removed because it's>> redundant:>>>> "To detect whether the window is currently visible. That is covered by>> the absence or presence of app.FrameEvents.">>>> Can you elaborate on this? I've instrumented my app to log FrameEvents>> and it stops getting them if the UI isn't changing (macOS & Linux X11,>> at least). It also doesn't seem to get any notification (aside from>> losing focus, if it had it) if it's iconified or "hidden" (e.g. Cmd-H>> to "hide" or any other app's cmd-alt-H to "hide others").>>>> The idea is that being iconified or otherwise hidden is not a reliable> notification> (e.g. Wayland doesn't report it), so it's more portable to use one of> the options> listed in the newsletter: window focus for "saving state"-like cases, lack of> FrameEvents to control animations and ViewEvent for managing the lifetime> of native resources tied to the window.>> Do you have a particular use-case in mind?>> Elias
On Sat, 20 Apr 2024 at 12:16, Felix Lange <fjl@twurst.com> wrote:
>> I have to say, I also hate this idea of detecting the ‘absence of FrameEvent’.> It adds a lot of complication to the app main loop, you have to:>> - have a separate goroutine with a timer> - reset the timer when there’s a FrameEvent> - trigger the app main loop with w.Invalidate or similar mechanism>
Usually, the "absence of FrameEvent" is for stopping rendering, which
is automatic,
and doesn't require timers etc.
Can you tell me more about your use-case? Perhaps there's a way to implement
your functionality while staying portable to platforms without
visibility notifications.
Thanks,
Elias
On Fri, Apr 19, 2024 at 11:00 AM Elias Naur <mail@eliasnaur.com> wrote:
> Do you have a particular use-case in mind?
Not as such, no, it just seemed like the suggested technique was
demonstrably less accurate than the old functionality.
Thanks for the reply.
-- Larry
I haven't upgraded to version 0.5 or 0.6 yet. I'm still on 0.1-ish. I'm hope to migrate
to 0.6 by June.
In the meantime, I use system.StageEvent for:
- Turning off Gio animations and components (like webview) when not visible.
- Implementing workarounds for Safari, due to limitations with onClick.
- Automatically filling in the sign-up confirmation code. If the user minizes the app
on "Enter Code" page and then returns, it will read the code from the clipboard
and check it in automatically (if it's a valid format).
As I said, I didn't move to 0.6, so I'm not sure if any of my use-case is affected.
--
Lucas Rodrigues
inkeliz@inkeliz.com
On Sat, Apr 20, 2024, at 2:38 PM, Larry Clapp wrote:
> On Fri, Apr 19, 2024 at 11:00 AM Elias Naur <mail@eliasnaur.com> wrote:>> Do you have a particular use-case in mind?>> Not as such, no, it just seemed like the suggested technique was> demonstrably less accurate than the old functionality.>> Thanks for the reply.>> -- Larry
On Sat, 20 Apr 2024 at 21:05, Lucas Rodrigues <inkeliz@inkeliz.com> wrote:
>> I haven't upgraded to version 0.5 or 0.6 yet. I'm still on 0.1-ish. I'm hope to migrate> to 0.6 by June.>> In the meantime, I use system.StageEvent for:>> - Turning off Gio animations and components (like webview) when not visible.> - Implementing workarounds for Safari, due to limitations with onClick.> - Automatically filling in the sign-up confirmation code. If the user minizes the app> on "Enter Code" page and then returns, it will read the code from the clipboard> and check it in automatically (if it's a valid format).>> As I said, I didn't move to 0.6, so I'm not sure if any of my use-case is affected.>
Hi Lucas,
All 3 use-cases sound to me that they can be implemented with
ConfigEvent.Focused.
Elias
Hi,
I have currently migrated almost everything to the latest version, but
ConfigEvent.Focused doesn't work.
I reported some issues about this on gio-todo. However, the issue affects multiple
OSes (from WASM to iOS) on different levels.
I can summarize all issues:
1. Focused is not triggered when the page is not visible (WASM). It happens before,
using visibilitychange.
2. Focused is triggered incorrectly if another view in the same window has focus,
but the Gio view doesn't. A bigger issue is identifying if the page is visible but not
in focus. Just because another activity/view has keyboard focus doesn't mean that
Gio is hidden (Android, macOS).
Focused doesn't reset the focus of the editors, so they remain "focused" even after losing keyboard focus (because another view/activity stole it).
Gio doesn't attempt to request keyboard focus or re-request the software keyboard when clicking on the Editor (Android, macOS, iOS).
--
Lucas Rodrigues
inkeliz@inkeliz.com
On Sun, Apr 21, 2024, at 7:50 AM, Elias Naur wrote:
> On Sat, 20 Apr 2024 at 21:05, Lucas Rodrigues <inkeliz@inkeliz.com> wrote:>>>> I haven't upgraded to version 0.5 or 0.6 yet. I'm still on 0.1-ish. I'm hope to migrate>> to 0.6 by June.>>>> In the meantime, I use system.StageEvent for:>>>> - Turning off Gio animations and components (like webview) when not visible.>> - Implementing workarounds for Safari, due to limitations with onClick.>> - Automatically filling in the sign-up confirmation code. If the user minizes the app>> on "Enter Code" page and then returns, it will read the code from the clipboard>> and check it in automatically (if it's a valid format).>>>> As I said, I didn't move to 0.6, so I'm not sure if any of my use-case is affected.>>>> Hi Lucas,>> All 3 use-cases sound to me that they can be implemented with> ConfigEvent.Focused.>> Elias
On Sun, 9 Jun 2024 at 22:35, Lucas Rodrigues <inkeliz@inkeliz.com> wrote:
>> Hi,>> I have currently migrated almost everything to the latest version, but> ConfigEvent.Focused doesn't work.>> I reported some issues about this on gio-todo. However, the issue affects multiple> OSes (from WASM to iOS) on different levels.>> I can summarize all issues:>> 1. Focused is not triggered when the page is not visible (WASM). It happens before,> using visibilitychange.>
This sounds like a regression, and not a fundamental issue with
ConfigEvent.Focused, right?
> 2. Focused is triggered incorrectly if another view in the same window has focus,> but the Gio view doesn't.
I believe your PR 138 fixes this issue.
> A bigger issue is identifying if the page is visible but not> in focus. Just because another activity/view has keyboard focus doesn't mean that> Gio is hidden (Android, macOS).>
Detecting whether the page is visible is not reliable, except for the
absence of FrameEvents.
What use-case are you referring to?
> Focused doesn't reset the focus of the editors, so they remain "focused" even after losing keyboard focus (because another view/activity stole it).
Also addressed by your PR 138, right?
> Gio doesn't attempt to request keyboard focus or re-request the software keyboard when clicking on the Editor (Android, macOS, iOS).>
I believe this is also fixed by your PR 138, right?
Thanks,
Elias