XScreenSaver 5.00 alpha 9

A new alpha, this time with binaries -- please give them a try, but don't be surprised if they wedge your computer and make you need to reach for the power button (I'm serious: the design of Apple's screensaver framework is dumb enough that this is an easy failure mode to achieve).

These are universal binaries, but 10.4 is required.

Please have a look at my todo list before running them.

I'm also interested in hearing about any problems you have with building/running the X11 version.

Questions for the Mac gurus:

  • Does the "Get Info" stuff in the various Info.plist files look sensible? (Does anything actually display CFBundleLongVersionString when CFBundleGetInfoString exists?)

  • What is the right way to eventually distribute these?

    • Is there any reason to use an installer instead of a .dmg?

    • What's the right way to automate the construction of that .dmg? Like, how do I make the icon for the "README" and whatnot go where I want it? Do I save and restore a magic .DS_Store file or something?

  • I can't figure out how to make the screen-grabbing code work. Help.

  • I can't figure out how to speed up XCopyArea. Help.

  • Is there some standardized way to say "this is the directory that image-manipulating screen savers should search for image files", or will each saver need to have its own preference for that?

  • I kinda hate how I had to add a "Shell Script" build phase to each target in XCode to get the right "Get Info" stuff into them. Well really what I hate is that the script runs every time you build whether anything has changed or not. Is there a better way to do this?

  • When I have to do stuff like "add a new build phase to each of the 200+ targets", is there any sensible way to automate that?

Tags: , , , ,

21 Responses:

  1. mpal1 says:

    I get a lot less warnings when I remove OSX/build/Debug from the library search path (The directory doesn't exist on a fresh build)

  2. grahams says:

    In my experience, I get pretty annoyed if an App uses an installer unnecessarily... Most of the screensavers I've gotten over the years have just been in zips or dmgs, and I'm pretty sure (but can't test here at work) that if you double-click a saver file the system will install it automatically (it may prompt the user first) and open the saver system preference pane.

    • taffer says:

      Another vote for DMGs (assuming this is a democracy). Installers always put things in the wrong location (no, I don't want a screen saver in /Library, dammit, go in ~/Library! *shakes fist ineffectively*).

    • jerronimo says:

      yes, but in this case, there are 200 saver modules. doubleclicking each of them would be insane. ;)

      the "SaverTester" app doesn't do anything on my system. (Powerbook G4 1.67ghz, 10.4.5)
      what's it supposed to do?

      • grahams says:

        It's only insane if you want to install all the modules...

      • jwz says:

        If you want to install them all, you can always just drag them to the savers directory. I guess I could ship a shell script that does that?

        I haven't tried using SaverTester outside of XCode; it's a simple test harness that loads a saver named in an env. var. and runs it in a pair of regular windows.

  3. taffer says:

    Here's some code that captures the screen, although it claims to be "slow". On the plus side, it's 100% Cocoa, so maybe it'll do.

    • taffer says:

      Figures, as soon as I hit the submit button, I notice that that code doesn't work in Tiger.

      I found this and this, but they're both Carbon.

      This might be what you're after.

      • jwz says:

        The first link you posted is the one linked to from my todo list, so yeah, I've seen that, and can't make it work. I've seen links 2 and 3 and they're gigantic and confusing and yes, not Cocoa/Quartz. And link 3 is QuickDraw, which is even more not-Quartz.

        My google-fu is not weak, you know.

        • edouardp says:

          I would never question your google-fu, but perhaps there is some stealable code in the source for OSXvnc or Desktop Manager? Both seem to do work with the screen. Yes - this is pretty weak, even as a pointer. Sorry.

        • edouardp says:

          Actually 3 looks pretty good considering most Mac OS X code usually uses 4 or 5 completely seperate APIs in one codebase. It's at least short and understandable (apart from the magic CopyBits dereferences).

          There *used* to be a NSDirectScreen, which gave you direct access to the raw bits of the screen, but I think that's no longer around (being a Yellow Box API...)

  4. wootest says:

    "When I have to do stuff like "add a new build phase to each of the 200+ targets", is there any sensible way to automate that?"

    Yes, AppleScript. Xcode has what must be one of the most complete scripting dictionary in all of OS X.

  5. alierak says:

    I doubt you're going to care, but I'm having to modify some code every time I want to try one of these alphas. I'm using MacOS X 10.3.9, with Apple X11, and get the following during "./configure; make":

    gcc -pedantic -Wall -Wstrict-prototypes -Wnested-externs -Wmissing-prototypes -std=c89 -U__STRICT_ANSI__ -no-cpp-precomp -bind_at_load -multiply_defined suppress -L/usr/local/lib -o xscreensaver-getimage xscreensaver-getimage.o ../utils/colorbars.o ../utils/resources.o ../utils/yarandom.o ../utils/visual.o ../utils/usleep.o ../utils/hsv.o ../utils/colors.o ../utils/grabscreen.o ../utils/logo.o ../utils/minixpm.o prefs.o -L/usr/X11R6/lib -lXpm -ljpeg -lSM -lICE -lXt -lX11 -lXmu -lXext -lm
    ld: Undefined symbols:
    _scale_ximage
    make[1]: *** [xscreensaver-getimage] Error 1
    make: *** [default] Error 5

    So, I go comment out this bit in driver/xscreensaver-getimage.c:

    #ifdef __APPLE__
    /* On MacOSX / XDarwin, the usual X11 mechanism of getting a screen shot
    doesn't work, and we need to use an external program. */
    # define USE_EXTERNAL_SCREEN_GRABBER
    #endif

    And of course, the usual X11 mechanism of getting a screenshot then works just fine.

    • taffer says:

      Change it to this and you don't have to comment it out:

      #if defined(__APPLE__) && !defined(HAVE_COCOA)

      That is, if my brain isn't munged and jwz is using HAVE_COCOA as the "native" symbol...

      • jwz says:

        Good guess, but xscreensaver-getimage.c isn't built at all in "native" mode.

      • alierak says:

        Well, I'm trying to avoid activating this code. On my system, __APPLE__ is defined. And HAVE_COCOA isn't, because it's only defined in <lj user="jwz">'s 10.4 xcode project, rather than by the configure script. So your change wouldn't change anything.

        I think the intent is to use an external screen grabber if
        - you're building the xcode project (HAVE_COCOA), or
        - you're using the XDarwin version of X11

        Neither of which I'm doing. How to distinguish between XDarwin and Apple X11 at build time, I have no idea.

    • jwz says:

      I think the real problem is that the "#ifndef USE_EXTERNAL_SCREEN_GRABBER" around scale_ximage should be "#if !defined(USE_EXTERNAL_SCREEN_GRABBER) || defined(HAVE_JPEGLIB)". (I'll bet you have HAVE_JPEGLIB and I don't.)

      I don't believe you that "the usual X11 mechanism works fine". Well, maybe it works if you run X11 in full-screen mode with its own root window and no Apple apps visible, but not if you run it in the sane, rootless way.

      • alierak says:

        Yeah, ok, I'll buy that. I figured it worked after running some hacks that do screen captures, not by code inspection.

  6. alierak says:

    Here's a patch for some problems with coral:

    - use of freed memory (st->pointbuf)
    - memory leaks at coral_free time
    - no pause between filling and erasing the window

  7. marapfhile says:

    I realize this is probably irrelevant by now, and I haven't tested the savers anyway, but how badly wedged are we talking about? If it's just a question of the UI not responding, it should be fairly easy to shell in from another box and kill the process in question.

    • jwz says:

      Yeah, that's as bad as it'll get, I think. A stuck (looping, but not crashed) saver will cause the Apple screen-saver driver to go catatonic and not un-blank.