shell: dismiss folder overlays when the launcher closes

[perlowja]

Opening an app folder creates an AppFolderOverlay, which is its own toplevel layer-shell window on the OVERLAY layer. Hiding the launcher does not take it down, and nothing dismisses it at close time.

The only thing that closes folder overlays is launcher_grid.depopulate(), and both close paths defer that to an idle timer:

private const uint IDLE_DEPOPULATE_MS = 45000;
...
_idle_depopulate_timer = GLib.Timeout.add(IDLE_DEPOPULATE_MS, () => {
    if (!is_showing) {
        launcher_grid.depopulate();   // <- the only thing that closes folder overlays

That timer exists to reclaim grid widgets, icon textures and preview buffers; overlay teardown is bundled into it incidentally.

So: open a folder, close the launcher, and the overlay stays on screen for 45 seconds. Reopen the launcher inside that window and the reopen branch cancels the timer —

} else {
    if (_idle_depopulate_timer != 0) {
        GLib.Source.remove(_idle_depopulate_timer);
        _idle_depopulate_timer = 0;
    }

— so depopulate() never runs and the overlay stays up until some later close plus a full idle.

This is a sibling of #51. The comment on force_close() notes that the animated close "depends on frame-clock ticks that stop once the launched window takes focus, leaving the overlay stuck on screen" — same defect via the launch path; this is the close-the-launcher path.

The fix

• close_folder_overlays() on AppLauncherGrid dismisses the overlays and nothing else.
• Both close paths in Overview — the animated close and finish_gesture_hide() — call it immediately.
• depopulate() keeps its idle timer and delegates the overlay half to the same helper, so the memory-reclaim behaviour is unchanged.

The overlay feature is untouched; only the moment it goes away changes.

One question for you

If folder overlays are meant to outlive the launcher and persist across a close/reopen, this is working as designed and you should close it. I do not think so, since the dismissal lives in a memory-reclaim path rather than anywhere intentional — but that is your call.

Reproduced on main, labwc 0.9.5 / wlroots 0.20.2, GTK 4.22.4.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f011b70517

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep frame-clock pulses paired across dock remaps

When an autohiding dock starts hiding and is revealed again within the 350 ms pulse window, this newly added unrealize creates a different surface/frame clock. pulse_frame_clock() begins updating the old clock at line 977, but its timeout fetches the current clock at lines 979-980; after this remap, the old timeout therefore ends the new clock early, and the new timeout later calls end_updating() on it again. This can truncate the reveal transition or trigger an unmatched frame-clock update warning during ordinary rapid pointer leave/re-enter, so the timeout should retain and end the same fc instance it began rather than looking it up again.

Useful? React with 👍 / 👎.