What to do with windows of inactive endpoint in Gateway sessions

[chrisfls]

Problem scope:

• You're using a gateway session while hacking someone;
• You have windows with an endpoint context;
• You change your active endpoint;

What happens with the endpoint context of your opened windows?

Options:

• A) Keep it as is:

Pros: Window fully usable, not many code changes needed.
Change: Will require a change to the window decoration to make endpoint explicit.
Cons: Having windows from multiple endpoints in the same session is confusing.

• B) Reload endpoint context of opened windows:

Cons: Player may lose data without explicit consent.
Change: Requires adding extra code to reload the window.

• C) Make the window read-only like we planned to do with windows of disconnected channels:

Cons: Player won't be able to interact with the window even with an active channel
Change: Requires adding extra behaviour for having read-only windows.

The first solution is probably the best, but I won't fix it without more input.

[renatomassaro]

Among these three, I think option C is the best, since A would get very confusing very fast (unless we make a very good job at displaying and switching contexts on the window title bar).

So I'd go with C and a big fat button "Switch endpoint" on the "read-only screen", in order for the user to quickly switch back and forth using the window itself (without having to select the proper server on the header dropdown).

A could be bearable if we make a very good UX job (change endpoint to server IP, use alias if the player specified one at the Database, paint the header with the remote server's background color, etc).

If we can make these UX improvements I'd go with A, otherwise C. Thoughts?