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
[coreimage] Update for Xcode 11[.2] #7216
Conversation
Apple decided to expose most (but not all) `CIFilter` using protocols (instead of weakly named dictionaries). Most of this maps well with our strong bindings but there are cases where we: * missing some properties (easy, there were added); or * used a different types [1] and that requires new members / obsoletion [1] Often ours are better (using `float` for a `bool` value is not optimal) but we do not have `[BindAs]` for protocols :( to _fix_ them Note: this replace draft PR xamarin#7120 but it's has quite a bit of changes in filter generation (inlining protocols) and that affected bindings too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-read everything and I could not spot anything so LGTM 👍
This PR is a beast :P
interface CIKeystoneCorrectionHorizontal { | ||
interface CIKeystoneCorrectionHorizontal : ICIKeystoneCorrectionHorizontalProtocol { | ||
|
||
#if false // no documentation about the type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we tried not to push dead code 😉. Couldn't it just be in the xtro ignore file with a comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's (almost) no headers for CIFilters, so no xtro reminders
almost because some stuff is now defined in protocols - and those are in headers, but the rest is not (it's all key/value based)
src/coreimage.cs
Outdated
// `CILinearGradientProtocol` is a bit of a lie - but it would not compile (registrar) otherwise | ||
interface CISmoothLinearGradientProtocol : CILinearGradientProtocol { | ||
|
||
/* we get those from ICILinearGradientProtocol |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if we're keeping this code in case it's ever added again, wouldn't a #if false
be better?
Similar to my comment above I don't know if we want dead code (:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, left over from the original attempt. I think that's fixed (properly) now. I'll uncomment it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uncommented (that scenario works fine now)
src/coreimage.cs
Outdated
@@ -2645,29 +2788,23 @@ interface CIImageProcessorKernel { | |||
[iOS (8,0)] | |||
[Mac (10,10)] | |||
[BaseType (typeof (CIFilter))] | |||
interface CIAccordionFoldTransition { | |||
interface CIAccordionFoldTransition : ICIAccordionFoldTransitionProtocol { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@spouliot I see you are using the I
version of CIAccordionFoldTransitionProtocol
is that intentional? IIRC you have to use the I
less version when doing this else the generator won't do the right thing.
Also I see this being mixed in the whole PR, for example the following does what I expect :)
interface CIAccordionFoldTransitionProtocol : CITransitionFilterProtocol {
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch, I'll review those
CIFilter
subclasses are generated differently that normal NSObject
so the end-result might be (nearly) identical. IOW I think my generator changes are not correct, with incorrect data giving the correct output.
src/CoreImage/CIFilter.cs
Outdated
if (v is NSNumber) | ||
return (v as NSNumber).NIntValue; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can it be done with just using the as? Like:
var n = v as NSNumber;
return n?.NIntValue ?? 0;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (v is NSNumber n)
return n.NIntValue;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was a copy/paste of the existing GetInt
method, but I can fix all of them
who's counting the lines anyway :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed in newer commits
src/CoreImage/CIFilter.cs
Outdated
{ | ||
return ValueForKey (CIFilterInputKey.Image) as CIImage; | ||
var v = ValueForKey (key) as CIVector; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as can return null, right? So unless we are 100% sure.. I'd check that.
src/CoreImage/CIFilter.cs
Outdated
using (var nsstr = new NSString (key)) | ||
return ValueForKey (nsstr) as CIImage; | ||
var v = ValueForKey (key) as CIVector; | ||
return new CGRect (v.X, v.Y, v.Z, v.W); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same.
|
||
[iOS (13,0)][TV (13,0)][Watch (6,0)][Mac (10,15)] | ||
[Field ("kCIImageAuxiliarySemanticSegmentationTeethMatte")] | ||
NSString AuxiliarySemanticSegmentationTeethMatteKey { get; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This look like they could be a smart enum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's actually a inside a type used tp create a strong dictionary [StrongDictionary ("CIImageInitializationOptionsKeys")]
but I did not add the keys to it :| I'll fix this
Makes me wish for #6785 even more
src/coreimage.cs
Outdated
|
||
[iOS (13,0)][TV (13,0)][Watch (6,0)][Mac (10,15)] | ||
[Static] | ||
[Wrap ("FromCGImageSource (source, index, options == null ? null : options.Dictionary)")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to change, but I think options?.Dictionary would be the same.
src/coreimage.cs
Outdated
IntPtr Constructor (CGImageSource source, nuint index, [NullAllowed] NSDictionary options); | ||
|
||
[iOS (13,0)][TV (13,0)][Watch (6,0)][Mac (10,15)] | ||
[Wrap ("this (source, index, options == null ? null : options.Dictionary)")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same options?.Dictionary should be the same.
[Static] | ||
[Export ("imageWithSemanticSegmentationMatte:options:")] | ||
[return: NullAllowed] | ||
CIImage FromSemanticSegmentationMatte (AVSemanticSegmentationMatte matte, [NullAllowed] NSDictionary options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know about the options? Could it be a strong dictionary?
|
||
[TV (13,0), iOS (13,0), Mac (10,15)] | ||
[Export ("initWithSemanticSegmentationMatte:options:")] | ||
IntPtr Constructor (AVSemanticSegmentationMatte matte, [NullAllowed] NSDictionary options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know about the options? Could it be a string dictionary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
string ? no, strong ? maybe :)
It was not documented before but now that
typedef NSString *CIImageOption;
was added we can be pretty sure it's the same as the one I mentioned above
However there's a lot of older members that also use NSDictionary
so, to keep this PR from calling unicorns, I'll fix that in a separate PR.
|
||
[iOS (13,0)][TV (13,0)][Watch (6,0)][Mac (10,15)] | ||
[Field ("kCIImageRepresentationSemanticSegmentationTeethMatteImage")] | ||
NSString SemanticSegmentationTeethMatteImageKey { get; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These look like they could be a smart enum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, but it's part of the type used for a strong dictionary: CIImageRepresentationOptions
I'll look if the types are documented, we are already missing a few of those
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, headers (not web doc) do mention the types of those (and the one we were missing from last year)
|
||
[Static] | ||
[NullAllowed, Export ("customAttributes")] | ||
NSDictionary<NSString, NSObject> CustomAttributes { get; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know anything about the attributes? Strong dict will be nicer if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Build failure Test results22 tests failed, 73 tests passed.Failed tests
|
src/generator-filters.cs
Outdated
// we can skip the name when it's identical to a protocol selector | ||
if (name == null) { | ||
if (export == null) | ||
throw new BindingException (9999, true, $"Missing [CoreImageFilterProperty] attribute on {type.Name} property {ptype}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actual error code is needed.
Also don't use string interpolation (we'll have to make everything use string.Format-syntax when we start translating text anyway).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm... how would translating {0}
be different from {ptype}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem isn't translating it, but using the translated string in C#. String interpolation requires the string to be a literal string, and translated strings aren't literal (https://stackoverflow.com/a/32360534/183422)
… ones) to simplify (all of) them
…nd remove [Watch] attributes since that framework is not (yet?) part of watchOS
Build failure |
Build failure |
build |
Build failure Test results9 tests failed, 86 tests passed.Failed tests
|
Build failure Test results2 tests failed, 93 tests passed.Failed tests
|
Build success |
…are used for other NSObject types
@mandel-macaque @dalexsoto your feedback should all be addressed now |
Build success |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM now 👍
Apple decided to expose most (but not all)
CIFilter
using protocols(instead of weakly named dictionaries). Most of this maps well with
our strong bindings but there are cases where we:
[1] Often ours are better (using
float
for abool
value is notoptimal) but we do not have
[BindAs]
for protocols :( to fix themNote: this replace draft PR #7120 but it's has quite a bit of changes in filter generation (inlining protocols) and that affected bindings too.