Dali Clock, 10.6

Before I dive in to getting xscreensaver to work on 10.6, I started smaller, and got the Dali Clock screen saver to work. Version 2.30 is out now. Please try it.

Unfortunately, I think the screen saver executable in there only works on 10.6, and the app and widget no longer work on 10.4, and I can't figure out how to fix that.

That's where you come in, dear Lazyweb.

To make it build on 10.6, I had to make these changes in XCode:

  • Architectures: Standard (32/64-bit Universal)
  • Base SDK: Mac OS X 10.5 (10.6 for the .saver)
  • C/C++ Compiler Version: GCC 4.0 (not 4.2)
  • Objective-C Garbage Collection: Supported
  • Info.plist: change "LSMinimumSystemVersion" from "10.4.0" to "10.4".

But it's obviously unacceptable that this should be a 10.6-only binary.

  1. How to I build DaliClock.app in such a way that it is runnable on 10.4, 10.5, and 10.6 systems?

    When I set the Base SDK to 10.4, I get "warning: Mac OS X version 10.5 or later is needed for use of the new objc abi", followed by "#error 64-bit not supported" from from objc/objc.h, included via Foundation.h.

    I suspect this means that you can't build a 10.4 version of the x86_64 binary, which is fine. Since 10.4 was perfectly happy running the i386 or ppc binaries, it's ok if the x86_64 build be 10.6-only, and the i386 and ppc builds be 10.4. But I don't see a way to specify that.

  2. How to I build DaliClock.saver in such a way that it is runnable on even 10.5 systems?

    When I set the Base SDK to 10.5, I get "ld: warning: in MacOSX10.5.sdk ScreenSaver.framework, missing required architecture x86_64 in file".

    Maybe this is the same kind of problem. But it's worse, because it means I can't build a 10.5-compatible version of the saver at all.

  3. How do I make these warnings go away?

    "AppController.m warning: passing argument 3 of 'addObserver:forKeyPath:options:context:' makes integer from pointer without a cast"

    The code in question is this, which had been warning-free before:

      [userDefaultsController addObserver:self
                forKeyPath:@"values.windowTitlebarIsHidden"
                options:nil
                context:@selector(windowTitlebarIsHiddenDidChange:)];
Tags: , , , , ,

16 Responses:

  1. mayoff says:

    I'll answer the easy one, #3. The argument after the "options:" keyword is type NSKeyValueObservingOptions, which is a typedef for NSUInteger. Change nil to 0 to eliminate the warning. (I tested only tested this on 10.5 but it did give/remove the warning for me.)

    • jwz says:

      Aha, cool. Thanks.

      I just spotted another new warning that I missed the first time:

      AppController.m:133: warning: class 'AppController' does not implement the 'NSWindowDelegate' protocol

      Any ideas on that one?

      • spastic_cow says:

        Objective-C seems to get bitchy if you don't declare that you implement a protocol even though, in the case of NSWindowDelegate, "all methods are optional." Change the definition of AppController in AppController.h to:

        @interface AppController : NSObject

  2. alzdran says:

    You can set up 3 targets: The first compiling ppc/i386 32-bit with the 10.4 SDK, the second compiling x86_64 for 10.6, and the 3rd a script based target which uses lipo to create a fat mach-o file combining the products of the first two.

    • jwz says:

      Unfortunately that's not practical for xscreensaver, where the project contains 200+ targets. I'd have to double that. It would be completely unmanageable.

  3. wfaulk says:

    Seems to work fine for me under 10.6 on my Mid-2007 MBP (MacBookPro3,1).

    However, I noticed that there is an empty file in the .saver and .wdgt packages named "Icon\r", where "\r" is 0x0D. It's not causing any problems or anything, but is that supposed to be there?

    • jwz says:

      Yeah, believe it or not, that's how you put an icon into a bundle. A file named "Icon\r" with nothing in the data fork and an image in the resource fork. Awesome, isn't it?

      • wfaulk says:

        Oh, wow. I didn't even realize they were using resource forks any more. But if they are, I suppose it makes sense for them to be using them in this doubly idiotic fashion.

        • jwz says:

          Pretty much the only thing that uses resource forks at all is Finder. Like: .webloc files store the URL in resources instead of in data. I cannot comprehend why they don't give up on resources already. Let it go, man. It's over.

          • tramp32123 says:

            Not so apparently. According to this interesting page: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3 Apple is overloading Resource Forks more and more. I suspect tricks like those described is why zfs got dropped.

            Cheers, Liam

            • rodgerd says:

              Noo, I think they dropped ZFS when they discovered some of it's more user-hostile behaviours, such as the one where, if you fill up a zpool, the only way to fix it is to remove a snapshot (you did have some, right), or, failing that, to add more disks and grow the pool, or back the pool up, destroy it, and recreate it. Because once it's full, you can't delete files any more.

              I can see that getting a warm welcome in the Apple usability labs.