jwz - XScreenSaver 5.00 alpha 9 [entries|archive|friends|userinfo]
jwz

  www.jwz.org
  userinfo
  archive
  rss

Links
[»| [DNA Lounge] [Blog] [iCal] ]
[»| [DNA Lounge Legal Defense Fund] ]
[»| [WebCollage] [LJ WebCollage] ]

XScreenSaver 5.00 alpha 9 [Thu, 9-Mar-2006 4:33 AM]
Previous Entry Add to Memories Tell a Friend Next Entry
[Tags|, , , ]
[music |My Life with the Thrill Kill Kult -- Hand in Hand]

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?
linkReply

Comments:
[User Picture]From: [info]mpal1
Thu, 9-Mar-2006 1:42 PM (UTC)

(Link)

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)
[User Picture]From: [info]grahams
Thu, 9-Mar-2006 2:25 PM (UTC)

(Link)

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.
[User Picture]From: [info]taffer
Thu, 9-Mar-2006 2:30 PM (UTC)

(Link)

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*).
[User Picture]From: [info]jerronimo
Thu, 9-Mar-2006 4:13 PM (UTC)

(Link)

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?
[User Picture]From: [info]grahams
Thu, 9-Mar-2006 4:16 PM (UTC)

(Link)

It's only insane if you want to install all the modules...
[User Picture]From: [info]jwz
Thu, 9-Mar-2006 9:23 PM (UTC)

(Link)

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.
[User Picture]From: [info]taffer
Thu, 9-Mar-2006 2:28 PM (UTC)

screen capture

(Link)

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.
[User Picture]From: [info]taffer
Thu, 9-Mar-2006 2:38 PM (UTC)

Re: screen capture

(Link)

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.
[User Picture]From: [info]jwz
Thu, 9-Mar-2006 9:28 PM (UTC)

Re: screen capture

(Link)

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.
[User Picture]From: [info]edouardp
Thu, 9-Mar-2006 10:59 PM (UTC)

Re: screen capture

(Link)

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.
[User Picture]From: [info]edouardp
Thu, 9-Mar-2006 11:29 PM (UTC)

Re: screen capture

(Link)

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...)
From: [info]wootest
Thu, 9-Mar-2006 5:17 PM (UTC)

AppleScript?

(Link)

"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.
[User Picture]From: [info]alierak
Thu, 9-Mar-2006 6:14 PM (UTC)

(Link)

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.
[User Picture]From: [info]taffer
Thu, 9-Mar-2006 9:09 PM (UTC)

(Link)

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...
[User Picture]From: [info]jwz
Thu, 9-Mar-2006 9:36 PM (UTC)

HAVE_COCOA

(Link)

Good guess, but xscreensaver-getimage.c isn't built at all in "native" mode.
[User Picture]From: [info]alierak
Thu, 9-Mar-2006 9:39 PM (UTC)

(Link)

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 [info]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.
[User Picture]From: [info]jwz
Thu, 9-Mar-2006 9:35 PM (UTC)

scale_ximage

(Link)

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.
[User Picture]From: [info]alierak
Thu, 9-Mar-2006 9:44 PM (UTC)

Re: scale_ximage

(Link)

Yeah, ok, I'll buy that. I figured it worked after running some hacks that do screen captures, not by code inspection.
[User Picture]From: [info]alierak
Thu, 9-Mar-2006 9:51 PM (UTC)

(Link)

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
[User Picture]From: [info]marapfhile
Tue, 14-Mar-2006 3:40 AM (UTC)

Kill From Shell?

(Link)

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.
[User Picture]From: [info]jwz
Tue, 14-Mar-2006 3:47 AM (UTC)

Re: Kill From Shell?

(Link)

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.