The Blog

New Omni framework source release

by Tim Wood on May 13, 2010

We've pushed new versions of our public framework source to github, featuring a bunch of work from our iPad apps, OmniGraffle and OmniGraphSketcher. Some of the highlights include our document picker, inspectors, a bunch of controls, and a start on a CoreText-based text editor, but there is much more.

For a quick iPad example, open up OmniGroup/Frameworks/OmniUI/iPad/Examples/TextEditor and build it. The text editing bit of this sample is a little rough, but this shows off some of the document picker.

Even if you aren't interested in adopting the frameworks directly, there are a bunch of little gems that you can use. One such feature is our Objective-C runtime sanity checker (in OmniGroup/Frameworks/OmniBase/OBRuntimeCheck.m).

The runtime checker helps avoid problems with mismatched method signatures between classes and their superclasses and between classes and conformed protocols. These can creep in as ABI changes from 32- to 64-bit support is added, or as subtle shifts in API happen in the system frameworks or your own class hierarchies. Some of these clang will check for you, but not all.

For example, having built OmniBase (with the Debug configuration, which enables this checking support) we can run Xcode with checking enabled (not to pick on Xcode, lots of apps have these problems):

% OBPerformRuntimeChecksOnLoad=1 DYLD_INSERT_LIBRARIES=/Users/Shared/bungi/Source/PROJ/Products/Debug/OmniBase.framework/OmniBase /Developer/Applications/Xcode.app/Contents/MacOS/Xcode?

...
2010-05-13 13:36:10.205 Xcode[19717:903] Method scriptWorkingDirectory has conflicting type signatures between class and its superclass:
signature i16@0:8 for class XCUserScript has imp -[XCUserScript scriptWorkingDirectory] at 0x100874d40 in DevToolsInterface.framework
signature @16@0:8 for class XCUserScriptNode has imp -[XCUserScriptNode scriptWorkingDirectory] at 0x100c8f870 in DevToolsInterface.framework
?...

?

Here we can see that a method's signature has changed — in one case it is returning an integer and in the other an object. Probably not a good sign.

By default, we silence problems where both sides of the conflict are in system frameworks (since we can't do anything about them). We've logged Radars on the in-system conflicts, but if you'd like to see them, you can also define OBReportWarningsInSystemLibraries in the environment:

2010-05-13 15:19:05.652 Xcode[21608:903] Method hash has conflicting type signatures between class and its superclass:

signature I16@0:8 for class CIVector has imp -[CIVector hash] at 0x7fff81e27e84 in QuartzCore.framework
signature Q16@0:8 for class NSObject has imp -[NSObject(NSObject) hash] at 0x7fff84862e80 in CoreFoundation.framework

Comments

Hey, Thanks for releasing the code. Just as an OBTW, the directions for pulling the source down from github need to be case sensitive. “git clone git://github.com/omnigroup/omnigroup OmniGroup” didn’t work for me, but “git clone git://github.com/omnigroup/OmniGroup OmniGroup”. Not up to speed with git (svn user), so maybe this is obvious to others…

charlie

charlie

05.14.10 12:44 PM
Team Member

Oops! Thanks for letting us know — I’ve updated the instructions.

For the curious, github didn’t seem to preserve the case of the repository name, but at some point it started working and I renamed the repository to ‘OmniGroup’ instead of ‘omnigroup’, but forgot to fix the checkout instructions.

Tim Wood

05.14.10 12:55 PM

Thanks very much, this is awesome!

Charles Parnot

05.14.10 1:45 PM

Any requirements for config in order to build this? I get errors in xcode and when building on the command line, I get the following:

The following build commands failed:
OmniFoundation:
  CopyStringsFile /Users/Shared/<user>/Products/Debug/OmniFoundation.framework/Versions/A/Resources/English.lproj/OmniFoundation.strings English.lproj/OmniFoundation.strings
  CopyStringsFile /Users/Shared/<user>/Products/Debug/OmniFoundation.framework/Versions/A/Resources/Language.strings Language.strings
  CopyStringsFile /Users/Shared/<user>/Products/Debug/OmniFoundation.framework/Versions/A/Resources/EnglishToISO.strings EnglishToISO.strings
  CopyStringsFile /Users/Shared/<user>/Products/Debug/OmniFoundation.framework/Versions/A/Resources/English.lproj/DateProcessing.strings English.lproj/DateProcessing.strings

Thanks.

paul

05.14.10 3:09 PM
Team Member

Did you set a custom build products location? I got another note that we haven’t documented that you need to do this.  In Xcode’s preferences, on the Building tab, you’ll need to have:

Place Build Products in:
[x] Customized location /Users/Shared/username/Products

Tim Wood

05.14.10 3:21 PM

I did. I still get over 700 errors trying to build TextEditor. It also can’t find the header files. I tried setting the header location in the build prefs(to .../OmniGroup/Frameworks) but to no avail. I am using xcode 3.2.2 on OS X 10.6.3.

paul

05.14.10 3:39 PM

You might take a look at the updated instructions on http://github.com/omnigroup/OmniGroup to see if those help.  If not, let me know (via a ticket, message or pull request) on github what does fix the problem and I’ll update the instructions so others can benefit from knowing how to work around whatever configuration issue you are seeing (or we can fix something in the source itself).

Tim Wood

05.14.10 7:03 PM

Awesome thanks guys.

Will this build with the latest beta ?

alxx

05.15.10 5:52 PM

Guys,

I’m trying to build some of the examples; the Place Build Products on the General tab of the Project settings, is that the one referred to in the instructions?  Couldn’t find a setting with the same label on the Build tab.

Thanks for releasing the code, though, guys.  Very informative…

John

05.20.10 1:28 PM

Nope, ignore me, figured it out…..

John

05.20.10 1:31 PM
Commenting is not available in this channel entry.