Improve experience with already activated frames

[jonathanmfung]

I think the user experience for a non-tabs-bar workflow could be improved. For reference, I use SwayWM on Wayland with system-configuration-options as -C --with-pgtk --with-native-compilation --with-json.

Expected behavior (activities-tabs-mode ON)

1. In tab 1 activities-resume for activity "foo". This renames the tab to "a: foo".
2. In tab 2 activities-resume for activity "foo". This correctly switches to tab 1.

Unexpected behavior (activities-tabs-mode OFF)

1. In frame 1 activities-resume for activity "foo". This renames the Wayland window to "a: foo".
2. In frame 2 activities-resume for activity "foo". This does nothing.

I believe activities-switch is interchangeable for activities-resume for both step 2's as they both use activities--switch.

--

My first suggestion was to use "window urgency", but I'm not aware if Emacs supports this, at least portably (SE ref).

Then I looked into how you handle already activated frames. I don't even know if select-frame (activities--switch) works on Wayland (similar bug-gnu-emacs ref). I relegate frame management to my WM, so don't really use select/raise-frame.

So my suggestion is to simply add a logging message in activities--switch that lets the user knows the selected activity is already activated somewhere.

[jdtsmith]

Why does raise-frame not work? For me (on mac) it switches mac tabs (which emacs sees as frames).

[jonathanmfung]

I believe raise-frame doesn't work because I use a tiling WM, so there isn't usually a notion of front/back.

However I just tried select-frame-by-name which, for me, doesn't actually switch focus, but at least sets window/workspace urgency. AFAIK Wayland doesn't expose a native way for programs to force focus, so compositors need to implement their own. (aforementioned bug-gnu-emacs ref, Gnome's, Sway's, Wayland spec).

select-frame-by-name uses select-frame-set-input-focus, so now I propose changing activities--switch's select-frame to that.

[jdtsmith]

select-frame-set-input-focus also raises, so I think this won't work generally because activities--switch is also called from a timer, to save the activity. So you'd get spontaneous raising/focus change.

One idea is to add an optional raise-and-focus argument to activities--switch, and use select-frame-set-input-focus in lieu of select-frame if this argument is non-nil, setting it only via activities-new, activities-resume, and activities-switch; i.e. "opt-in" to raising instead of using the dynamic binding.

[alphapapa]

It sounds like this behavior needs to be configurable, so probably the way to handle it would be for the user to add a function to activities-after-resume-functions that does whatever is desired (showing a message, calling a different frame-related function, etc).

[alphapapa]

Please see the new option, activities-after-switch-functions. You can use that to customize what happens after switching to an activity.

[jdtsmith]

Maybe now you can remove the raise-frame hack from activities--switch, since frame people can add that to the hook (there could well be people who do not want to raise resumed frame).

[alphapapa]

Maybe now you can remove the raise-frame hack from activities--switch, since frame people can add that to the hook (there could well be people who do not want to raise resumed frame).

¯\_(ツ)_/¯

Seriously, though, I feel like that one should stay, because what good is a selected frame if it's buried beneath other frames or apps. But if some users actually complain about it and want it removed or optional, we'll see.