jh@ist.CO.UK (Jeremy Huxtable) (07/27/90)
A frivolous question.... Having got bored of 'Pyro', I wrote my own firework display as an application but would like to make it work as a screen saver. I can see two routes to this. One is the Multifinder-wait-in-the-background-application route but this suffers from all sorts of disadvantages, especially as I don't understand Multifinder and would like this to work under the ordinary Finder as well. The second method is to patch one or more toolbox traps. I tried patching GetNextEvent and EventAvail, and this works fine under Finder, but fails under MultiFinder. With MultiFinder, the patch is called much less frequently, and erratically. My quesition is: is there a known and approved method of writing a screen saver which anyone would care to share with me? Which traps should be patched, and what should be done to make the thing MultiFinder friendly? One of the Tech. Notes mentions screen savers, but a) doesn't go into any detail and b) seems to expect different things from a screen saver than I do (I want it to cut in automatically after X minutes idleness and cut out again on a mouse movement or other event). Thanks, Jeremy Huxtable P.S. I'll send it to the net if I get it working.
ari@eleazar.dartmouth.edu (Ari Halberstadt) (01/11/91)
I know the basic idea of a screen saver: if nothing's happened for X minutes, then blank the screen (gee whiz). I've written an application which will blacken the entire screen (or screens), and wait till there's a click or some other user event. I've even written a patch to GetNextEvent which, for lack of anything better to do, beeped if nothing had happened for several minutes. What I need is a screen saver which will work both in Finder and in MultiFinder. It can be an INIT, like AutoIdle. I have several questions: If I write it as an INIT, like AutoIdle, and patch GetNextEvent, then I need some way to blacken the screen. AutoIdle seems to patch InitGraf as well, so that it can find out if it's been called. If InitGraf hasn't been called, then I guess AutoIdle calls it. To blacken the screen, all I'd have to do is create a port and paint it black. The problem is, how do I tell the application to redraw its windows when it's time to unblacken the screen? Also, I'm not sure that I can always create a graf port if InitGraf isn't called by the application. Under MultiFinder, assuming I wrote a background program, how do I examine the event queues of all of the applications? And, how do I force a background application's window to be the frontmost window when it's time to blacken the screen? One technique, employed by a shareware utility, is to launch another application as a foreground application which will blacken the screen. How do I make sure all of this works under A/UX 2.0? (This requirement isn't that critical, but it's always nice to be compatible.) I understand A/UX doesn't have the same type of event queue that regular macs have. Thanks folks. If I get enough replies, maybe I'll post a summary. ------- cut here if you think tail patches are good for your digestion ------ The following comment has had bloody battles fought over it, but since I'm talking about patching GetNextEvent, I sort of feel it's my duty to state this. NOTICE MAC PROGRAMMERS: Tail patches are bad. Inside Macintosh says you shouldn't do them (lookup SetTrapAddress). Please don't start a flame war, it's just that I still see source code with tail patches in it. Someday I'll post an assembly language and C stub showing how to write friendly patches.
mlab2@kuhub.cc.ukans.edu (01/11/91)
> The problem is, how do I tell the application to redraw its > windows when it's time to unblacken the screen? I believe you just post an UpdateEvent. john calhoun
d88-jwa@dront.nada.kth.se (Jon W{tte) (01/12/91)
In article <1991Jan11.171935.3488@ux1.cso.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes: >driver journal events and pass them along to check for idle time. Since The Joournalling mechanism is "owned" by MacroMaker these days. Apple says we shouldn't use it. (Besides, it doesn't work very well under A/UX) >a device driver can do nasty things at accRun time like Quickdraw routines, >you can just do exactly what your application does to blacken the screen. What about a faceless background task calling SystemTask() ... ? >And drivers should be supported ad infinitum and under AUX. HAH ! Not many drivers are supported, since they have to run in user mode and don't mess with hardware or memory mappings or just about anything. H+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se