Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GameController][Xcode12] Updates through beta 4 #9265

Merged
merged 10 commits into from
Aug 7, 2020

Conversation

whitneyschmidt
Copy link
Contributor

@whitneyschmidt whitneyschmidt commented Aug 3, 2020

No description provided.

[DisableDefaultCtor] // return nil handle -> only exposed as getter
partial interface GCGamepad {

[NullAllowed]
//[NullAllowed] This seems like it's a breaking change...
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a breaking change? 🤔 It doesn't seem like it. Any code that assumes that a null may be returned will still work here - we're restricting the return value to a subset of what it used to be.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think changing this has any effect on our generated code (IOW it's fine).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK it is not an issue at all. It is a get and not a set, so we do not care. @whitneyschmidt on a 'set' we do check for the value and throw a NRE depending on the value, but since we only return, we are fine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope not a breaking change

[Export ("supportedLocalities", ArgumentSemantic.Strong)]
NSSet<NSString> SupportedLocalities { get; }

// Dependency on Xcode 12 CoreHaptics bindings
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this guy. It is in my feedback report, thanks for the headsup :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to link to the issue here for easier record keeping? :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could add it here #8943

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like CoreHaptics is blocked on AVAudioSession for Mac bindings :(

https://github.com/xamarin/maccore/issues/2261

GCControllerButtonInput PaddleButton4 { get; }
}

[Static] // I tried moving GCKey and GCKeyCode to separate files, but ran into
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way for GCKey and GCKeyCode to live in their own files?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible, but it's somewhat of a special case.

Basically you'd have to add it like xkit.cs is added here:

AppKit XKit \

I don't think it's worth it to have binding code in a separate file, xkit.cs is literally the only exception, and that's only because we want the code in both UIKit and AppKit at the same time.

[DisableDefaultCtor] // return nil handle -> only exposed as getter
partial interface GCGamepad {

[NullAllowed]
//[NullAllowed] This seems like it's a breaking change...
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think changing this has any effect on our generated code (IOW it's fine).

src/gamecontroller.cs Outdated Show resolved Hide resolved
src/gamecontroller.cs Outdated Show resolved Hide resolved
src/gamecontroller.cs Outdated Show resolved Hide resolved
GCControllerButtonInput PaddleButton4 { get; }
}

[Static] // I tried moving GCKey and GCKeyCode to separate files, but ran into
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible, but it's somewhat of a special case.

Basically you'd have to add it like xkit.cs is added here:

AppKit XKit \

I don't think it's worth it to have binding code in a separate file, xkit.cs is literally the only exception, and that's only because we want the code in both UIKit and AppKit at the same time.

src/gamecontroller.cs Outdated Show resolved Hide resolved
src/gamecontroller.cs Outdated Show resolved Hide resolved
[DisableDefaultCtor] // return nil handle -> only exposed as getter
partial interface GCGamepad {

[NullAllowed]
//[NullAllowed] This seems like it's a breaking change...
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK it is not an issue at all. It is a get and not a set, so we do not care. @whitneyschmidt on a 'set' we do check for the value and throw a NRE depending on the value, but since we only return, we are fine.

@@ -202,7 +226,7 @@ partial interface GCGamepadSnapshot {

[iOS (7,0)]
[Mac (10,9)]
[BaseType (typeof (NSObject))]
[BaseType (typeof (GCPhysicalInputProfile))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All this base changes are ok, but do remember that changing a base COULD be a breaking change. Not in this case since GCPhysicalInputProfile is a NSObject and it was the parent of the old class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be listed as a breaking change but there is nothing we can do about it, if a base changes we have to honor that

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This case technically should not be an issue. Others might: https://docs.microsoft.com/en-us/dotnet/core/compatibility/#types

REQUIRES JUDGMENT: Introducing a new base class

A type can be introduced into a hierarchy between two existing types if it doesn't introduce any new abstract members or change the semantics or behavior of existing types. For example, in .NET Framework 2.0, the DbConnection class became a new base class for SqlConnection, which had previously derived directly from Component.

Comment on lines 529 to 535
[TV (14, 0), Mac (11, 0), iOS (14, 0)]
[Export ("acceleration")]
GCAcceleration Acceleration { get; }

[TV (14,0), Mac (11,0), iOS (14,0)]
[Export ("setAcceleration:")]
void SetAcceleration (GCAcceleration acceleration);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Method and a property? That is very weird? Acceleration and SetAcceleration do look like a perfect candidate for a property.

[Export ("supportedLocalities", ArgumentSemantic.Strong)]
NSSet<NSString> SupportedLocalities { get; }

// Dependency on Xcode 12 CoreHaptics bindings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this guy. It is in my feedback report, thanks for the headsup :)

@monojenkins
Copy link
Collaborator

Build success
Build succeeded
API Diff (from stable)
⚠️ API Diff (from PR only) (🔥 breaking changes 🔥)
ℹ️ Generator Diff (please review changes)
Test run succeeded

Comment on lines 529 to 535
[TV (14, 0), Mac (11, 0), iOS (14, 0)]
[Export ("acceleration")]
GCAcceleration Acceleration { get; }

[TV (14,0), Mac (11,0), iOS (14,0)]
[Export ("setAcceleration:")]
void SetAcceleration (GCAcceleration acceleration);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[TV (14, 0), Mac (11, 0), iOS (14, 0)]
[Export ("acceleration")]
GCAcceleration Acceleration { get; }
[TV (14,0), Mac (11,0), iOS (14,0)]
[Export ("setAcceleration:")]
void SetAcceleration (GCAcceleration acceleration);
[TV (14, 0), Mac (11, 0), iOS (14, 0)]
[Export ("acceleration")]
GCAcceleration Acceleration { get; set; }

[Export ("supportedLocalities", ArgumentSemantic.Strong)]
NSSet<NSString> SupportedLocalities { get; }

// Dependency on Xcode 12 CoreHaptics bindings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could add it here #8943

Comment on lines 700 to 722
[Field ("GCHapticsLocalityDefault")]
NSString LocalityDefault { get; }

[Field ("GCHapticsLocalityAll")]
NSString LocalityAll { get; }

[Field ("GCHapticsLocalityHandles")]
NSString LocalityHandles { get; }

[Field ("GCHapticsLocalityLeftHandle")]
NSString LocalityLeftHandle { get; }

[Field ("GCHapticsLocalityRightHandle")]
NSString LocalityRightHandle { get; }

[Field ("GCHapticsLocalityTriggers")]
NSString LocalityTriggers { get; }

[Field ("GCHapticsLocalityLeftTrigger")]
NSString LocalityLeftTrigger { get; }

[Field ("GCHapticsLocalityRightTrigger")]
NSString LocalityRightTrigger { get; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if these should be grouped on their own static class or smart enum depending on how they are used for example

[Static]
interface GCHapticsLocality {

	[Field ("GCHapticsLocalityDefault")]
  	NSString Default { get; }
 
  	[Field ("GCHapticsLocalityAll")]
  	NSString All { get; }
 
  	[Field ("GCHapticsLocalityHandles")]
  	NSString Handles { get; }
 
  	[Field ("GCHapticsLocalityLeftHandle")]
  	NSString LeftHandle { get; }
 
  	[Field ("GCHapticsLocalityRightHandle")]
  	NSString RightHandle { get; }
 
  	[Field ("GCHapticsLocalityTriggers")]
  	NSString Triggers { get; }
 
  	[Field ("GCHapticsLocalityLeftTrigger")]
  	NSString LeftTrigger { get; }
 
  	[Field ("GCHapticsLocalityRightTrigger")]
 	NSString RightTrigger { get; }
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done!

Comment on lines 724 to 725
[Field ("GCHapticDurationInfinite")]
float DurationInfinite { get; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if we should remove the Haptic part, else I am unsure what infinite duration is it about

Suggested change
[Field ("GCHapticDurationInfinite")]
float DurationInfinite { get; }
[Field ("GCHapticDurationInfinite")]
float HapticDurationInfinite { get; }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 😄

Comment on lines 765 to 766
[Notification, Field ("GCKeyboardDidDisconnectNotification")]
NSString DisconnectNotification { get; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[Notification, Field ("GCKeyboardDidDisconnectNotification")]
NSString DisconnectNotification { get; }
[Notification, Field ("GCKeyboardDidDisconnectNotification")]
NSString DidDisconnectNotification { get; }

src/gamecontroller.cs Outdated Show resolved Hide resolved
Comment on lines 846 to 848
[BaseType (typeof (NSObject))]
[Protocol]
[Model]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[BaseType (typeof (NSObject))]
[Protocol]
[Model]
[Protocol]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha! So we can have just [Protocol] if we remove [Model] and [BaseType...]! So [Model] and [BaseType...] always go together but [Protocol] can be independent. Thank you @dalexsoto :)

Comment on lines 851 to 862
[TV (9, 0), Mac (10, 9), iOS (7, 0)]
[Abstract]
[Export ("handlerQueue", ArgumentSemantic.Strong)]
DispatchQueue HandlerQueue { get; set; }

[TV (9, 0), Mac (10, 9), iOS (7, 0)]
[Abstract]
[NullAllowed, Export ("vendorName")]
string VendorName { get; }

[TV (13, 0), Mac (10, 15), iOS (13, 0)]
[Abstract]
[Export ("productCategory")]
string ProductCategory { get; }

[TV (14, 0), Mac (11, 0), iOS (14, 0)]
[Abstract]
[Export ("physicalInputProfile", ArgumentSemantic.Strong)]
GCPhysicalInputProfile PhysicalInputProfile { get; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The availability attributes do not make sense here, specially since the container protocol is [TV (14,0), Mac (11,0), iOS (14,0)] so someone is lying to us

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is bizarre because the availability attributes in the header match these ones...but it's impossible for that to be true. I'm thinking we should just leave the container protocol's availability attribute and remove the rest of them so that everything has [TV (14,0), Mac (11,0), iOS (14,0)].


[Export ("objectForKeyedSubscript:")]
[return: NullAllowed]
GCControllerElement ObjectForKeyedSubscript (string key);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
GCControllerElement ObjectForKeyedSubscript (string key);
GCControllerElement GetObjectForKeyedSubscript (string key);

NSString RightGui { get; }
}

[TV (14, 0), Mac (11, 0), iOS (14, 0)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indentation :)

@whitneyschmidt whitneyschmidt added this to the xcode12 milestone Aug 4, 2020
@spouliot spouliot mentioned this pull request Aug 4, 2020
46 tasks
@monojenkins
Copy link
Collaborator

Build failure
Build succeeded
API Diff (from stable)
⚠️ API Diff (from PR only) (🔥 breaking changes 🔥)
ℹ️ Generator Diff (please review changes)
🔥 Test run failed 🔥

Test results

3 tests failed, 73 tests passed.

Failed tests

  • introspection/Mac Modern/Debug: Failed (Test run failed.)
  • introspection/iOS Unified 64-bits - simulator/Debug (iOS 10.3): TimedOut
  • introspection/tvOS - simulator/Debug (tvOS 10.2): Failed

[Static]
[TV (14, 0), Mac (11, 0), iOS (14, 0)]
partial interface GCKey
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation is space here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! Thank you 😄


using System;

using CoreFoundation;
using Foundation;
using ObjCRuntime;
using OpenTK;
//#using CoreHaptics; // need CoreHaptics update for TV 14.0 inclusion
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR with support for CoreHaptics on tvOS landed on the xcode12 branch: #9273

@whitneyschmidt whitneyschmidt changed the title [GameController][Xcode12] Updates through beta 3 [GameController][Xcode12] Updates through beta 4 Aug 5, 2020
@monojenkins
Copy link
Collaborator

Build success
Build succeeded
API Diff (from stable)
⚠️ API Diff (from PR only) (🔥 breaking changes 🔥)
ℹ️ Generator Diff (please review changes)
Test run succeeded

Comment on lines 402 to 408
// iOS 14 beta 3 (to be reviewed)
case "GCDeviceBattery":
case "GCDeviceLight":
case "GCDualShockGamepad":
case "GCKeyboard":
case "GCMouse":
case "GCXboxGamepad":
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this and the one below filled as an issue somewhere? So we do not forget to review these in the future or you could check for a specific Xcode Version in the tests so they fail if not fixed in the future, also if you consider this to be an Apple mistake file a bug :)

@@ -535,4 +616,1157 @@ interface GCEventViewController {
[Export ("controllerUserInteractionEnabled")]
bool ControllerUserInteractionEnabled { get; set; }
}

[TV (14,0), Mac (11,0), iOS (14,0)]
[BaseType (typeof( NSObject))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[BaseType (typeof( NSObject))]
[BaseType (typeof (NSObject))]

@monojenkins
Copy link
Collaborator

Build success
Build succeeded
API Diff (from stable)
⚠️ API Diff (from PR only) (🔥 breaking changes 🔥)
ℹ️ Generator Diff (please review changes)
Test run succeeded

@whitneyschmidt whitneyschmidt merged commit 1f77d1b into xamarin:xcode12 Aug 7, 2020
@whitneyschmidt whitneyschmidt added iOS Issues affecting Xamarin.iOS macOS Issues affecting Xamarin.Mac note-highlight Worth calling out specifically in release notes labels Sep 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
iOS Issues affecting Xamarin.iOS macOS Issues affecting Xamarin.Mac note-highlight Worth calling out specifically in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants