Cleaning up warnings in the Mac glass code

[Martin Fox]

I can set this up to exclude deprecation warnings. When I turn on warnings-as-errors and exclude deprecations there are only a handful of changes needed in glass. I think they could be handled in a single pull request. I’ll need an issue number; will I be able to enter a bug for this through the public portal?

I don’t want to hide deprecation warnings entirely since they do sometimes flag issues worth investigating (one is now on my to-do list). It’s still a lot of warnings so it’s probably worth coming up with a strategy for reducing them over time. 

> On Nov 29, 2021, at 10:10 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> I agree that this would be a good thing to aim for as long as we exclude deprecation warnings (given Apple's penchant for deprecating large API surfaces such as OpenGL or the older accessibility APIs we really can't have the use of deprecated APIs be an error).
> 
> -- Kevin
> 
> 
> On 11/24/2021 7:44 PM, Michael Strauß wrote:
>> That's a good idea. In general, warnings should always be treated as errors.
>> 
>> 
>> On Thu, Nov 25, 2021 at 2:01 AM Martin Fox <martin at martinfox.com> wrote:
>>> The Mac glass code generates a lot of compiler warnings. I tried cleaning this up and discovered that two of the warnings are brand new, courtesy of me. One of the headers in PR #651 has a typo that I didn’t catch and neither did the two reviewers. The compiler generated two warnings but they were lost in the sea.
>>> 
>>> I turned on warnings-as-errors for the Mac glass code and waded through the results. There are a couple of minor coding errors in addition to mine which should be cleaned up (like passing NO to a function that requires a non-null pointer). There’s also a few deprecated calls across a small handful of files which have easy replacements and are probably worth fixing.
>>> 
>>> Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated the older forms (I think this was to rationalize the naming with Swift). These form the bulk of the warnings and affect multiple files. Not a fan of that sort of code churn but the alternative is to live with a slew of warnings forever. Apple is not going to un-deprecate those constants.
>>> 
>>> You can see the changes I made in my github repository (beldenfox/jfx) in the branch ‘macwarnings’. There’s multiple commits, the first and biggest catching most of the easy stuff like constant renaming.
>>> 
>>> In the short term it might be worth disabling deprecation warnings and turning on warnings-as-errors. Then at least outright coding errors (like mine!) have a chance of being caught.
>>> 
>>> 
>>> 
>>> 
>