Minor renamings of some APIs

[ethanc8]

This commit implements Apple's renaming of some APIs, such as another enum NSProgressIndicatorStyle that Apple had renamed in order to allow it to be parsed by the Swift compiler, the new typedef typedef NSString *NSPasteboardType;, and the -[NSViewController view{Will|Did}{Appear|Disappear}] variants which take no arguments.

[gcasa]

It would be best to, instead of renaming them, do a similar version ifdef for the version of macOS this change was made in. We always want to be as backwards compatible as possible. It is okay in an enum for multiple names to be assigned the same value.

[ethanc8]

It would be best to, instead of renaming them, do a similar version ifdef for the version of macOS this change was made in. We always want to be as backwards compatible as possible. It is okay in an enum for multiple names to be assigned the same value.

I did not rename any APIs -- I just added the new APIs, and the enums have been defined. I might need to add some guards around the new enum names, though.

[gcasa]

It would be best to, instead of renaming them, do a similar version ifdef for the version of macOS this change was made in. We always want to be as backwards compatible as possible. It is okay in an enum for multiple names to be assigned the same value.

I did not rename any APIs -- I just added the new APIs, and the enums have been defined. I might need to add some guards around the new enum names, though.

I apologize, I wasn't clear, this is what I meant. It's so that if someone is using a particular version of the API they don't have access to the enums under the new names.

[fredkiefer]

Looks good

[fredkiefer]

Could you please add the #ifdef that Gregory requested so we can merge this.

[ethanc8]

Could you please add the #ifdef that Gregory requested so we can merge this.

I will do that tomorrow.

[ethanc8]

I have rebased it on master and will try updating the patches soon.

[ethanc8]

@fredkiefer @gcasa I believe this is ready to merge into master. The CI errors are due to unrelated issues with the workflow YAML definitions.

[fredkiefer]

I think the call order should be the other way around. That is in viewWillAppear we should call viewWillAppear: with NO.

[ethanc8]

Apple's docs indicate that developers are supposed to override viewWillAppear. viewWillAppear: seems to be a GNUstep extension; it never appears in NSViewController.h.

[ethanc8]

So if in viewWillAppear we call viewWithAppear:NO people will subclass NSViewController and implement viewWillAppear, but any calls to viewWillAppear:NO in gnustep-gui will bypass their implementation. But if in viewWillAppear: we call viewWithAppear, we will use people's implementations in their subclasses whenever gnustep-gui calls viewWithAppear:NO.