Posts Tagged ‘Mac’

When TISGetInputSourceProperty( *, kTISPropertyUnicodeKeyLayoutData) returns NULL

I happened to use Korean input method when I launched a S/W program. Then it crashed at accessing the resultant object of TISGetInputSourceProperty().

They say Japanese keyboard caused returning NULL. I will add Korean input method to that.

Here are two things to be aware of :

  • What is interesting is that kTISPropertyUnicodeKeyLayoutData is still used when it queries last ASCII capable keyboard.
  • It is TISCopyCurrentASCIICapableKeyboardLayoutInputSource() not TISCopyCurrentASCIICapableKeyboardInputSource() to call. The latter doesn’t guarantee that it would return an keyboard input with a layout.

Xcode 5 creates properties ( member variables ) for @property like this

For people who doesn’t trust me.

This is original behavior of creating a member variable for a @property.

Very interesting bug of Objective-C

When a member variable (aka property in SmallTalk term, semantically same to @property, but member variables are called “property” in SmallTalk. ) is accessed using self.<property name> through the @property mechanism or just <member variable> name, sometimes the result is different.

different values

HPLIP : HP Linux Imaging and Printing project for Mac

According to their main page, HPLIP doesn’t work on Mac.

However I found a bug fix page for which the bug fixer mentioned it worked like charm.

I’d like to check the status of this project.

Difference between Objective-C compilation for Mac and iOS for 32 bit

For past several years, Apple people tried to make kernel for Mac and iOS identical.In Snow Leopard, they got rid of PowerPC code and started to introduce 64 bit kernel.

On Lion, as far as I know, kernel version of iOS caught up that of Mac OS X. So, after that it’s widely said that kernels for iOS and Mac are the same.
However, Apple recently introduced 64bit iOS for iOS 7. So, although the kernel for Mac was built as 64bit, iOS was built 32bit so far.
Anyway, the trend is that Cocoa becomes similar and Objective-C compiler becomes similar in feature list they support.

However, I noticed that 32bit compilation for Mac is not up-to-date compared to that for iOS.

Here is the difference between the two.

32bit compilation for Mac OS X (on the left) and iOS (on the right)

32bit compilation for Mac OS X (on the left) and iOS (on the right)

Although the overall direction is to make them identical on Mac OS X and iOS identical, it turns out that Apple didn’t update 32bit compilation for Mac to match that for iOS. The 64 bit runtime on Mac OS X is so called ‘modern run-time’. But should the run-time different for Mac and iOS?
I’m not sure because I don’t know the detailed story about what happened at Apple.

Because I have worked for iOS recently, i thought that 32 bit build environment for OS X would be the same to 32 bit environment for iOS. But it was not.
Apple’s official feature matrix can be found here.
What doesn’t catch is that modern runtime is only for 64 bit on Mac.


Maybe Apple people consider Mac OS X/iOS hybrid apps?

The last time I looked up documentation on “How to build iPhone/iPad hybrid app” was 2 years ago roughly. (When did the 1st gen. of iPad come out?)

At that time, I think there was no “platform key” in this identifier format in info.plist.


According to a section “updating your info.plist settings” in “Creating a Universal App”, it says :

For apps that run only on iOS, you can omit the platform string. (The iphoneos platform string is used to distinguish apps written for iOS from those written for Mac OS X.)

Hmm… what does that mean? Are they preparing a unified executable file format like they did for 32/64 and Intel/PowerPC for iOS and Mac OS X?
So, you can choose whether a project is built for Mac OS X or iOS, or the both?
Surely, iOS uses ARM instruction set in Mach-O format ( I believe ) while Mac OS X uses x86/x64 instruction set in Mach-O format. then…. yeah.. it can be possible to have one bundle.

Hmm.. if they announce a Mac-iPad hybrid device, it can be interesting. I like Lenovo’s effort on this with Windows 8.


difference in auto synthesis and “traditional” synthesis

After the introduction of iPhone SDK, many things have been changed very quickly.
Some were changed very publicly, while some didn’t. Even though there is no explanation on those changes, you could figure out some by taking a look at basic template code which Xcode puts by default.
However, some are hidden.
I was away from iOS/Mac development for a while and tried to catch up stuff recently. One of the simple but astonishing one was the internal member variable Objective-C preprocessor creates.

For example, let’s say that interface file looks like this.

@interface JAWindowController : NSObject

@property (retain, nonatomic) IBOutlet UIToolbar *toolBar;
@property (retain, nonatomic) IBOutlet UIButton *buttonOne;
@property (retain, nonatomic) IBOutlet UITextView *textViewOne;


Then when ARC is off and auto synthesis is used, it creates those internal variables which matches their properties with “_” prefixed to the property name.

#import "JAWindowController.h"

@implementation JAWindowController

- (void)dealloc
	[_buttonOne release];
	[_textViewOne release];
	[_toolBar release];
	[super dealloc];

However, if explicit synthesis is used, it will create the default internal variable names same to their property names like this.

the red underlines means a variable with such a name doesn't exists.

the red underlines means a variable with such a name doesn’t exists.

When ARC is on, it’s the same like the case of ARC is off. The only difference is that it doesn’t create dealloc message for you automatically, because usually it’s not necessary because Objective-C objects are to be released automatically by ARC mechanism.

%d bloggers like this: