InfinitePIP development journal · Part 4 of 5
A better workspace for all your PiPs
Dashboard navigation, capture controls and a more deliberate packaging process.
Once you're using several floating views, the main window needs to do more than offer a source picker. The August InfinitePIP candidate brought in a dashboard, source workbench, Active PiPs view, settings and diagnostics, using the same general visual direction as Bourbon and the macOS driver suite.
The practical flow is still simple. Choose a display or application window, or define a custom screen region, then adjust the resulting PiP independently. Zoom, pan, opacity and always-on-top controls help the view fit around the work you're already doing.
Permission and source state became more explicit too. On macOS, Screen Recording access belongs to the actual app identity. A development Electron process having permission doesn't tell us whether the packaged InfinitePIP app can capture. Protected media can also intentionally refuse capture, which a new dashboard can't override.
Underneath the interface, the candidate moved to Electron 44 and added more deliberate release checks. Local developer packages were kept separate from signed release commands. Packaged legal notices, Electron fuse settings and fresh artifact checksums became things we could inspect instead of assumptions attached to a file in the output folder.
The dated changelog calls 26.8.30 a public-release candidate. At this point in the chronology, signing and packaged runtime checks were still gates. The later September upload record supplies evidence that goes beyond that earlier candidate description.
What I like here is the combination of a more usable main window and a clearer path to delivery. Both matter: the app needs to make multiple PiPs manageable, and the download needs a record of what was actually built and checked.
InfinitePIP development journal
View the journalLive5 entries so far·Updated New (5 entries updated in the last 14 days)