From what I gather so far, at the given time where there is no keyboard or mouse activity, the o/s calls the screensaver controller program which, based on which screensaver is chosen, runs a given .saver screensaver, which I presume is *probably* just a regular exe file (not sure). It might not be, as I think I read that the saver is actually a whole folder containing several parts as a `bundle`. What I can tell is that the exe file has to usually use the `screensaver framework` which is mainly screensaver/screensaver.h include file, plus some functions which encapsulate certain pieces of code. I'm not sure why those functions have to have certain names - it's almost as if they are called from somewhere else within the app. I think possibly that the header files include the basic routines to a) open an NView single-buffered screen, b) set up a timer which then c) calls the `animateoneframe` function - which you can define the contents of, at the given interval. So I'm thinking that the header file handles opening the display, setting up a frame timer for flipping, and calling the functions to initialize/shutdown and do one frame of animation. The question is, do we even NEED this header to do that for us, if blitz were going to provide ability to handle flipping, graphics set up and other routines. Another point to consider is there is a function referring to whether a configuration panel is defined, and another that actually creates and operates the panel. It seems the panel has to be attached to a `sheet` which I guess is a sliding gui panel that drops down in the system prefs screensaver window. So it looks like you'd have to tap into and use an o/s compatible GUI arrangement - ie wouldn't be able to really use MaxGUI, or be able to integrate MaxGUI with the system prefs.
Thoughts following this are, maybe we would have to settle for a screensaver that detects the keyboard and allows a given `config` key to be pressed which then displays a graphics-based or popup-maxgui-based config window, but it wouldn't be embedded in the system prefs and presumably might not show in the preview window. The question then leads to - how do we get the preview window working. It seems you have to use the NSView display as given by the o/s in order to have it be scaled down and rendered in the preview. So then - how to integrate the NSView with Max's graphics display so that Max's display shows in the o/s preview window.
Seems like some complicated stuff that would have to be hacked together at a low level. OR.... use XCode to compile, use the o/s's framework for screensavers, and have the screensaver in Objective C call functions in an included blitz app or .a file or whatever. Who knows.
An alternative is to bypass the system screensaver altogether, go with the old fashioned screensaver system like `after dark` which monitors key and mouse input and handles the triggering of the saver, which could all be within one blitz app. But it would not be part of the system screensaver prefs - which would've been really nice.
Unfortunately it is not as simple as windows. You don't get parameters passed to a regular exe file to tell it what to do, and you don't get to open your own screen or handle your own frame timing or use your own gui system or open your own config window in whatever form you like. Windows actually has a lot more freedom that way. Mac being somewhat more proprietary requires that you play nicely with the o/s, which makes it hard for BlitzMax.
Thoughts following this are, maybe we would have to settle for a screensaver that detects the keyboard and allows a given `config` key to be pressed which then displays a graphics-based or popup-maxgui-based config window, but it wouldn't be embedded in the system prefs and presumably might not show in the preview window. The question then leads to - how do we get the preview window working. It seems you have to use the NSView display as given by the o/s in order to have it be scaled down and rendered in the preview. So then - how to integrate the NSView with Max's graphics display so that Max's display shows in the o/s preview window.
Seems like some complicated stuff that would have to be hacked together at a low level. OR.... use XCode to compile, use the o/s's framework for screensavers, and have the screensaver in Objective C call functions in an included blitz app or .a file or whatever. Who knows.
An alternative is to bypass the system screensaver altogether, go with the old fashioned screensaver system like `after dark` which monitors key and mouse input and handles the triggering of the saver, which could all be within one blitz app. But it would not be part of the system screensaver prefs - which would've been really nice.
Unfortunately it is not as simple as windows. You don't get parameters passed to a regular exe file to tell it what to do, and you don't get to open your own screen or handle your own frame timing or use your own gui system or open your own config window in whatever form you like. Windows actually has a lot more freedom that way. Mac being somewhat more proprietary requires that you play nicely with the o/s, which makes it hard for BlitzMax.