Make Port-forward UI Better

[indexds]

Hello,

1- Custom port-forward UI: Custom... currently expects free-form input with only an example as guidance. Could we mirror k9s's three explicit fields: Container Port, Local Port, Address?

2- Shortcut parity: Fullscreen logs are shift+f here vs f in k9s; port-forward delete is x in :pf vs ctrl+d used everywhere else (and in k9s). Could we align this?

3- Port-binding feedback: Currently there is no indication that a port is already bound before attempting to forward. Could we get a marker (e.g. a red dot on bound ports and a green one on unbound?) on the port to avoid discovering the failure only after pressing enter?

[nklmilojevic]

Thanks for writing these up!

Quick note on framing first - sofka is inspired by k9s, but it's a separate product with its own keymap and UI. Matching k9s isn't a goal, so "k9s does it this way" alone won't move things. A problem in sofka itself will :)

1. Custom port-forward input - agreed, free text with only an example isn't great. I'd change Custom… to a small form with remote port and local port, with the local port pre-filled to the remote one. The address already comes from portForwardAddress in config, so I'd only add it to the form if people really need to change it per forward.

2. Shortcuts - I'll keep these as they are. f on a pod or service starts a port-forward in sofka, and shift-f is fullscreen across all document views, not only logs. In :pf, x stops a forward and saved forwards stay in the list, so nothing gets deleted. ctrl-d is a real delete with a confirm prompt, and I don't want the two on the same key. If you prefer k9s muscle memory, you can remap the keys in your own config: https://github.com/nklmilojevic/sofka/blob/main/docs/keybindings.md

3. Port-binding feedback - good one, finding out only after enter is late. I'd check each local port when the picker opens and mark the busy ones as in use. I'd use text, not red/green dots: color alone isn't accessible, and a teal ● already means an active forward. The port can still get taken between opening the picker and pressing enter, so the current error stays as a fallback.

So 1 and 3 are a go, 2 stays as is. I'll create an issue for 1 and 3 and link it here.

[nklmilojevic]

Created #894 for 1 and 3. Closing this one, follow along there :)