Add focus_follows_drop option to focus window on drop done

[cxa]

Add a new focus_follows_drop option (default: no) that, when enabled, automatically focuses the window that receives a drop.

The problem

When using splits, dropping something onto a non-active window delivers the drop content correctly (via window.on_drop()), but keyboard focus remains on the previously active window. The user has to manually click the target window after every drag-and-drop to continue working in it.

The fix

A new boolean option focus_follows_drop (default: no). When enabled, tab.set_active_window(window) is called before window.on_drop(drop) in Boss.on_drop(), so the window that receives the drop also receives keyboard focus.

What's changed

• kitty/options/definition.py — new focus_follows_drop option
• kitty/options/types.py — generated type entry
• kitty/boss.py — guard set_active_window behind get_options().focus_follows_drop

What's NOT affected

• Tab dragging (application/net.kovidgoyal.kitty-tab-* path) — unchanged
• Window dragging (application/net.kovidgoyal.kitty-window-* path) — unchanged
• Tab bar drops — unchanged
• Single-window tabs — the guard window is not tab.active_window makes this a no-op
• Default behavior — unchanged (focus_follows_drop defaults to no)

Testing

1. Add focus_follows_drop yes to kitty.conf
2. Open kitty with splits layout
3. Focus the left split
4. Drag something onto the right split
5. Before: drop content arrives in right split, but keyboard focus stays on left split
6. After: right split receives both the drop and keyboard focus

[kovidgoyal]

I am not at all sure this is desired behavior, unless
focus_follows_mouse is set to true (in that case it changes focus
anyway). Do other programs behave this way?

[cxa]

I tried focus_follows_mouse but it’s annoying, lots of unexpected behavior outside of drag-and-drop.

[kovidgoyal]

Yeah but other people will find focus_follows_drop annoying. As I said
is there some precedent for this? Does dropping things into unfocused OS
Windows from other applications focus them? Do some research.

For example, on macOS, drag and drop from focused finder does not
transfer focus from finder to the dropped application.

[cxa]

OK you convinced me. Let’s add an option (focus_follows_drop) for it, disabled by default, people who are interested can opt in.

[kovidgoyal]

1. No need for a separate option. Simply change focus_follows_mouse to a choices type option, with choices being (y, yes, true, n, no, false, drop). The drop choice means that focus only follows mouse on drops not movement. You will need to write a special ctype parser for the option.

2. on_drop does not actually handle all drops. It's only called for drops that are kitty UI related. You can also have drops onto terminal programs (see dnd-protocol.rst). You need to handle this option in both cases.

[cxa]

Thanks for supporting this option!