Skip to content
This repository has been archived by the owner on Jan 18, 2021. It is now read-only.

Several mostly straightforward changes #3

Open
wants to merge 74 commits into
base: master
Choose a base branch
from

Conversation

seanm
Copy link

@seanm seanm commented Jan 31, 2014

Martin, if you're still interesting in this old project of yours, I'd appreciate a review of these changes… It's mostly straightforward, and I've taken care to make it reviewable. Thanks!

seanm and others added 30 commits November 16, 2009 11:53
(cherry picked from commit 5acfd8c)
…s default compiler

Important since gcc 4 is long gone in recent Xcodes, and such Xcodes give an error.
Fix mismatch between delegate method declarations and implementations,
implementation was missing protocol qualifier. Fix various compiler warnings
in the test app related to delegates. Made MainController conform to MultiClickRemoteBehaviorDelegate.
Cleanup of awakeFromNib implementation which had redundancies in setting the AppleRemote delegate.
Made MultiClickRemoteBehavior conform to RemoteControlDelegate.
Identifiers that start with underscore and uppercase are reserved,
but in any case it was not need at all.
In several places this project has parameters names that start with underscore,
which in Cocoa generally indicates an ivar, this is very confusing.
Renamed all "_remoteControlDelegate" to "inRemoteControlDelegate".
I chose the "in" prefix to be sure I don't conflict with any ivar name.
In several places this project has parameters names that start with underscore,
which in Cocoa generally indicates an ivar, this is very confusing.
Renamed all "_cookieToButtonMapping" to "inCookieToButtonMapping".
I chose the "in" prefix to be sure I don't conflict with any ivar name.
In several places this project has parameters names that start with underscore,
which in Cocoa generally indicates an ivar, this is very confusing.
Renamed all "_delegate" to "inDelegate".
I chose the "in" prefix to be sure I don't conflict with the ivar name, which has no underscore!
Different files were using different character encodings for curley quotes
in the license text, just use ASCII quotes.
As per Cocoa convention.  This touches many files, but should be a pretty safe change
since I used Xcode 5's refactor tool to do the renames (and doubled checked it).
When I renamed ivars to start with underscore,
I missed the fact that 'remoteBehavior' was bound to
from the nib. There was no 'remoteBehavior' accessor
so the bounding was made invalid.

Took this opportunity to use the first @Property
in this codebase.  This is still compatible back to 10.5
and gcc 4.
The horizontal separator had a subview for some reason, removed it.
The nib's deployment target was and still is 10.5.  Updated read me
to remove implication that 10.4 is still supported.
seanm added 30 commits January 31, 2014 20:31
Instead, use CF APIs to accomplish the same thing.  CF APIs have the same
memory management rules in MRC, GC, and ARC.

These changes are more extensive than my previous changes, and so
the risk of regression is higher.
…ead of [super dealloc], as per current Apple recommendations
The actual remote code only really needs Foundation
(after changing OS version check from NSAppKitVersionNumber to NSFoundationVersionNumber),
but it technically needs AppKit.h too for the IBAction declaration.

The test app needs AppKit for the UI of course.
Many are in fact not atomic anyway, so this was the right choice for them.
Others could be atomic, but the 'atomic' keyword was only recently available,
so not backwards compatible enough.  Not specifying either OTOH gives
warnings in new versions of clang.
- Added a few #defines to help conditionalize code to support MRR, GC, and ARC.  A little messy, but not so bad.
- Added (conditional) bridge casts as necessary for ARC.
- Conditionalized NSAutoreleasePool vs @autoreleasepool
- Removed a @synthesize in favour of manual implementation to avoid needing messy conditional assign/weak/unsafe_unretained
- Conditionalized dealloc/finalize per memory model

Still compiles back to OS 10.5 & Xcode 3.1.4.
It is always more correct to check the return value
before looking at the returned-by-reference value.
Workaround rdar://12665902.

kIOReturnExclusiveAccess isn't really a constant,
it's a macro that performs undefined shifts into the sign bit.

This causes both a compiler warning from -Wshift-sign-overflow
and a runtime crash under clang UBSan.
It was impossible to set breakpoints otherwise.

Also consistently use braces, even for one line `if` statements.
…1) in the enum

Also, since a negative value is possible:
- make sure to use signed methods to convert to/from NSNumber
- explicitly make the enum (signed) int
- favour alloc/init over new
- specify @reqired in protocol declaration
- other very minor changes
- changed abstract base class AppleRemote remoteControlDeviceName method to return emtpy string instead of NULL
- now assert required/non-null parameters
Opened the xib in Xcode 7.2.1 (7C1002) on Mac OS X 10.10.5 (14F2511), the oldest I have running.  And touched the file, saving with 10.5 deployment and Xcode 5.1 compatibility.
This is a quite small change to the xib, but necessary for Xcode 11.3.1 and later to even build the test app.
Performed on Mac OS X 10.10.5 (14F2511) with Xcode 7.2.1 (7C1002).
- 10.13 and 10.14 needed fixes for just two buttons, plus and minus
- 10.15 and 11.0 changed considerably, all the cookies changed completely, and so none of the buttons worked before this fix
- added helper method to determine OS version
- added some commented-out debugging logs
- Mention support for both Apple Remotes
- Mention macOS versions tested
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants