IlyaP358/fluxcast

_iw_p2p_check returns ok as soon as iw dev shows a type P2P-device, and puts the whole raw output into the detail field. It never looks at what else is in there. A group interface left behind by a crashed or interrupted session appears in that same output as a p2p-* netdev of type P2P-client or type P2P-GO. The check prints it and calls the row ok. From #136, this is what the doctor showed before the session had even started: ok iw P2P kernel exposes a P2P-device interface (... Interface p2p-wlo1-7 | ifindex 11 | type P2P-client | ... type P2P-device ...) p2p-wlo1-7 was left over from an earlier attempt, and the machine was sitting there believing it was already a client in a group. Three of us read that report without noticing, because it is buried inside an ok row along with everything else iw dev prints. It should warn instead: name the interface, say it looks left over from a previous session, and give the command to remove it. Worth doing now rather than after the leaks themsel

--doctor tells people iw and wpa_cli are missing when they are installed. Three rows from the same report in #146, on Debian sid: ok dnsmasq NetworkManager P2P DHCP server (/usr/sbin/dnsmasq) warn iw kernel Wi-Fi interface inspection (not found in PATH) warn wpa_cli active Wi-Fi Direct scan/control (not found in PATH) All three live in /usr/sbin. dnsmasq is found because it hands extra_paths=["/usr/sbin/dnsmasq"] to _find_binary. The other two go through a bare shutil.which, which only looks at PATH, and /usr/sbin is not in a normal user's PATH on Debian or Ubuntu. On Arch it is a symlink to /usr/bin, which is why none of us ran into it. It is not only cosmetic. There are four bare shutil.which calls: diagnostics.py:484 and :522, which also produce the "iw was not found" row peers.py:64, where _default_wifi_interface() returns None peers.py:113, where active_scan() gives up with "wpa_cli is required" The third is the one that hurts. _default_wifi_interface()

The Support button in the About window is drawn on a canvas of a fixed width, KOFI_W = 300 in ui/tray.py, with the label centred on it. Any translation wider than that spills past the button shape, and anything wider than the canvas is cut off. Measured at the default font scale, button 300px, canvas 354px:   rendered result pt 361px truncated de 321px spills past the button onto the glow es 318px spills past the button onto the glow fr 285px fits en 268px fits da, ru, cs, sv under 270px fit The ratio is unchanged at larger font scales, so this is not something a bigger window fixes. It is separate from #134, which was about the window and is closed. The button should size itself to the rendered width of its label rather than to a constant, so no language has to be shortened to fit the layout.

Summary On KDE/GNOME Wayland the portal backend is the only capture path --doctor can meaningfully vouch for, but it only verifies 2 of the 11 GStreamer elements that path actually requires. The result is a clean-looking report followed by a session that dies the moment capture starts. What the doctor checks src/diagnostics.py:835-845 registers exactly two element checks: _gst_element_check( "pipewiresrc", ... _gst_element_check( "x264enc", ... What the portal backend requires _start_desktop_portal in src/wfd/media/portal.py:258-266: required = ( "pipewiresrc", "videoconvert", "videoscale", "x264enc", "mpegtsmux", "rtpmp2tpay", "udpsink", ) if not self.config.no_audio: required += ("pulsesrc", "audioconvert", "audioresample", "aacparse") plus an AAC encoder resolved at runtime by _gst_pick_aac_encoder (fdkaacenc / avenc_aac / voaacenc / faac), which raises WFDNotReady when none is presen

Reported by @Volondil while testing #62. When casting a single window, audio still comes from the default sink's monitor, so everything the machine plays goes to the TV: notifications, a voice call, a video playing in another window. Casting one window for privacy while sending all desktop audio defeats half the point. _detect_audio_monitor() in src/wfd/env.py runs pactl get-default-sink and appends .monitor. The ScreenCast portal carries no audio at all, so nothing links the window we captured to an audio stream. It has to be solved on the PipeWire side, by capturing the application's own sink-input instead of the sink monitor. --wfd-audio-device already accepts any monitor source, so a reasonable first step is listing the running applications from pactl list sink-inputs and letting the user pick one, rather than expecting them to set up a null sink by hand.