One call window, its controls, then a recording
A video-call app’s window has a camera, a screen-share button and a status banner, and later a network monitor and a recorder. Like the lesson’s panels and their desk, each control should report to the window, and the window decides what the others show. Each level starts from the previous level’s finished code, so you can begin at any of them.
On a poor connection the app saves bandwidth by hiding your camera, and the banner says poor connection. Your screen share keeps going. When the connection recovers, the camera comes back, but only if you still want it and are not presenting. Two things can now hide the camera at once, and either can end first.
Today a poor connection changes nothing, so calls freeze. A rule written event by event (“on poor, hide; on good, show”) brings the camera back while the user is still presenting, or turns it on for a user who switched it off.
Reproduce w.input("poor") should hide the camera and say poor connection; today nothing changes. And after w.input("share"); w.input("poor"); w.input("stop") the connection is still poor, so the camera should stay off; a handler that only looks at its own event brings it back.
Acceptance criteria While the connection is poor, the camera is hidden and the banner says poor connection; sharing continues. When the network reports good, the camera returns only if the user wants it and is not presenting. The banner lists every notice that applies, poor connection first, then presenting, separated by a comma and a space, or - when none does. Everything from MEDIATOR-101 still holds, the host’s stop included. Notes Each case prints camera=on|off share=on|off banner=<text>, as before. The inputs poor and good are the network monitor’s reports. Keep the window’s input method and the fields the checker reads (camera.on, share.sharing, banner.text).