This sometimes doesn't work correctly because we may want to change the
native scaling even when the user scaling is constant. Additionally, the
number of calls to update is not as much as anticipated so the performance
savings is minimal.
Due to the way prefersPointerLocked works, if the pointer is currently over
a SwiftUI button, it will trigger every time the mouse is clicked. We
swizzle in a new property that allows us to ignore all indirect touch events
when active.
Fixes#4843
In preparation for multiple-display support, the existing view controller is
decoupled from UTMVirtualMachine and UTMSpiceIO and now interfaces solely
with VMDisplayViewControllerDelegate. This allows us to then wrap the VC into
a UIViewControllerRepresentable and isolate much of the state into
VMWindowState (a single window) and VMSessionState (entire VM). Finally, the
loading screens are re-implemented in SwiftUI.
The old backend was very limiting because of how it wrapped a dictionary into
an Objective-C class. It made working with SwiftUI awkward because of the
nested objects and lack of clean array support. It also makes using Swift
Concurrency difficult.
The new config backend unifies both the Apple and QEMU config formats which
were previously separate. This also allowed for much duplicate code to be
removed (particulary in the FS handling of disk images and load/saving).
A temporary UTMConfigurationWrapper class is implemented to interop with the
Objective-C backend mostly for QEMU support.
This was broken in the re-factor. We fix the functionality and also
clean up the code and make it so the persistent value is always up to
date.
Fixes#3669
Additionally expose APIs for Swift 5.5 concurrency support (currently
unused). This should simplify the handling of various interdependent
events that must come together for startVM and other operations. It also
opens the door for future async handling of VM operations when better
support for Cocoa, UIKit, and SwiftUI comes.
This gives us a few main advantages:
1. It improves encapsulation and division of responsibility.
2. CocoaSpice can be used in other projects more easily.
3. It lays the foundation for better unit testing of key parts.
4. It cleans up the codebase.
Resolves#2376
There was a misunderstanding previouly that the input code and
cursor drawing code should reside in the same class. This led to
one CocoaSpice class handling both the SPICE input and cursor
channel. The problem is that SPICE protocol specifies a 1-to-1
mapping of cursor channel and display channel (sharing the same
channel id). To implement support for multiple displays, we
would have to follow this convention.
Additionally, there was some akwardness in forcing CSInput to
comply with the UTMRenderSource protocol because it shared the
viewport size with CSDisplay. "Outside" code would have to
syncronize the display size.
As part of the refactor, we also tried to improve the code style
by first moving as many ivars to properties as possible and by
also renaming some methods and inits.
osy