- src: xscreensaver-5.00a9.tar.gz -- danger, toxic, do not distribute!
bin: xscreensaver-5.00a9.dmg -- danger, toxic, do not distribute!
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?
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)
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.
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*).
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?
It's only insane if you want to install all the modules...
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.
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.
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.
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.
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.
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...)
"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.
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 -lmld: 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:
And of course, the usual X11 mechanism of getting a screenshot then works just fine.
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...
Good guess, but xscreensaver-getimage.c isn't built at all in "native" mode.
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.
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.
Yeah, ok, I'll buy that. I figured it worked after running some hacks that do screen captures, not by code inspection.
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
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.
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.