• dockable has been changed to pipify
• developer no longer manages the PipifyController (simplifying implementation)

@State var showPip = false

someView
  .pipify(isPresented: $showPip) // uses self as the view (morph effect)

// or

someView
  .pipify(isPresented: $showPip) {
    SomeOtherView() // uses view in closure as the view (fade effect)
  }

// optional:
// in your view you can add the controller as an environment object

@EnvironmentObject var controller: PipifyController

// this gives you access to the renderSize etc
// alternatively:

yourPipifyView
    .onPipRenderSizeChanged { size in
        // new size goes here
    }

Closes #5 Closes #10

Looking at the examples, I'm not seeing the view being updated with the width and height information. In my application that uses Pipify, I'm also not seeing the view being re-rendered even though the code in setView's renderer.objetWillChange is being called.

I'm passing a simple view into the Pipify modifier, and the resulting rendered view (text and images) is of low quality. It's like it's scaling up from the view. I tried setting the renderer.scale property but that didn't seem to affect anything. This is evident in the Example project as well. Is there a trick to get high quality text and images in the Pip view?

Progress on #10 Closes #13

Work in progress, likely to require more structural changes to provide custom modifiers for this.

Ideally the play/pause button would only 'work' (store changes) if a closure is provided. Likewise the skip buttons should only be active if a closure is provided for those.

At present, we use a hidden view to transition into the PiP state. This can make the transition a bit jerky and potentially confusing. It would be nice to give the developers the option to dock an existing view instead of docking a hidden view.

This would be achieved by removing the content: parameter in the existing dockable modifier. If no content is provided, the attached view is docked. If content is provided, that is docked instead.

It would be good to share examples in the community (whether tweets, code samples, or released apps) so people can be inspired and see it in action.

https://apps.apple.com/us/app/minispeech-live-transcribe/id1576069409 - released application https://twitter.com/jordibruin/status/1543247957482405888 - proof of concept

We should explore the possibility of having a single controller being able to manage multiple views at the same time. It appears Apple does not like you have multiple picture in picture controllers in the lifecycle at once.

Allow users to interact with the play/pause button and potentially even the skip forward/backwards button and have the view change as a result of that.

The combination of the pipController.requiresLinearPlayback = true and the CMTimerange hides the backwards and forwards controls.

I'm not sure what the CMTimeRange needs to be so let's triple check that stuff

Apple provides us with a delegate call whenever the render size of the PiP window is changed. This is because not only does Apple themselves mostly decide the size, but also the user can resize the window.

Some clients may wish to dynamically change what content is shown based on how large the window is on the screen - as such it would be good to route this information through to the view when we render it. This could likely be done with a custom environment key.

We need to ensure we're providing a suitable amount of structured logging in order to aide with debugging and implementation.

We should ensure that we're providing a good separation between warnings/errors and general information - perhaps with opt-ins through a log level.

We may consider using swift-log.

When you build the sample app or an app based on the SPM using Xcode 14.0.1, it SwiftUI PIP view seems to have been replaced by a gray view with a spinner in it. If you close the PIP window, you see the correct SwiftUI view for a brief moment before the PIP disappears.

Try to run the example project on macOS 13 Beta 5 (build number: 22A5321d), then it crashed on startup with EXC_BAD_ACCESS error, log below:

2022-08-16 02:05:10.214520+0800 Sample[18556:300581] [User Defaults] Couldn't read values in CFPrefsPlistSource<0x600001008980> (Domain: com.apple.powerlogd, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access
2022-08-16 02:05:10.495536+0800 Sample[18556:300581] [Pipify] creating pip controller
2022-08-16 02:05:10.496087+0800 Sample[18556:300581] [Pipify] creating pip controller
2022-08-16 02:05:10.532626+0800 Sample[18556:300581] *** Assertion failure in NSPoint _NSViewClampPointToLimits(NSView *, NSString *, NSPoint)(), NSView.m:640
2022-08-16 02:05:10.533196+0800 Sample[18556:300581] Invalid parameter not satisfying: fabs(point.x) <= NSVIEW_GEOMETRY_LIMIT
2022-08-16 02:05:10.538790+0800 Sample[18556:300581] [Pipify] setting view content
2022-08-16 02:05:10.539346+0800 Sample[18556:300581] [Pipify] setting view content

It looks like crash on makeNSView(_:) in LayerView. Maybe https://github.com/utmapp/UTM/commit/d5ba4fb7f32cc80a7489043b22d8e6c73a591851 helps.

This library definitely relies on a few 'tricks' and so it's going to be an interesting challenge to add a number of UI and snapshot tests to prove that it works as intended.

We should look to use UI tests as a way to follow a step by step set of instructions and snapshot each step of the way to prove that the device looks and is responding as expected. Specifically, we should be clearly seeing the PIP window launch with the right content and prove that it's updating dynamically.

Alongside a much richer sample app with numerous examples showing the different capabilities, we also want to provide a DocC documentation bundle with rich real-world examples with simple to follow instructions.

We should look at adding one or more DocC tutorials to allow people to follow along at home.

I also feel like from a contributing perspective I should add an architecture diagram which better explains exactly how all of this works.

SwiftUI redraws views often, this is a big part of it's architecture to allow for quick and dynamic updates to views. Unfortunately, this causes issues with Pipify because it regenerates the PIP controller every time.

This has been seen in this Twitter thread (https://twitter.com/aoverholtzer/status/1546249575748358144) and my own experiences.

We need to ensure we protect against this.

Currently we do not enforce the isSupported check - it would be logical to move this up into the PipifyModifier so we're not adding extra load onto unsupported devices.

We should also make sure we're adding a log message (warning) so developers are aware of this.

Notably, this will detect simulators which causes some weird edge cases at the moment.