Thanks for another release of my favorite linux app.
Out of curiosity (and please excuse my ignorance about Macs) are you going to make version of XScreenSaver that works natively with the Macintosh screensaver subsystem (if there is one) or is that unfeasible?
Given that xscreensaver is really an alternate screensaver subsystem... Itym "are you going to port the xscreensaver hacks."
Alternatively, we could modify an X windows server to run as a macintosh screensaver.
Hehe. That would be one hilarious waste of time.
So, you're either a moron or completely unfunny. Which is it?
You realize that it runs on MacOS right now, using the available X subsystem?
Yeah. But that's not what <lj user="johnxp"> and <lj user="grumpy_sysadmin"> were talking about. There are apparently downsides to running xscreensaver that way.
It would probably take way way more effort, and I'm not trying to say it would be a good idea, but it could be done and it would obviate porting the xscreensaver hacks. It would work, right?
As others have pointed out, that really means "port the hacks to the native saver framework." Yeah, I'd like to do that, but I haven't gotten around to it.
It should be relatively easy to port the OpenGL hacks (probably just a few ifdefs), but the X11 hacks will take some more doing. For the X11 hacks, I'm thinking the way to go is to basically write a tiny version of Xlib that implements only the pieces that xscreensaver happens to need, and shims between the X API and Cocoa. (The goal being to keep the same pile of source code building on both systems, rather than forking it all.)
Another thing that would be nice to have is some code that reads the XML files that are used to describe the per-hack xscreensaver-demo GUI configuration stuff, and emits Cocoa controls, so that the Mac versions would have sliders and stuff.
Mostly I haven't started playing with this (or with porting XDaliClock) because I'm still avoiding getting over the learning curve of XCode. I'm just really, really not looking forward to learning how to use that behemoth. If someone were to send me some proof-of-concept on the Mac side of this stuff, it might give me a kick in the pants...
Something like..<http://www.javasaver.com/testjs/jws/03/ant.jnlp> ? **
(That should default to the Mac 'Aqua' PLAF, though I do not know how close that comes to the Cocoa 'Look and Feel').
Alternately, a quick perusal of the NIB files suggests to me (I don't run OSX) they (can) use XML to describe the widgets. So it might be possible to devise an XSLT that transforms the savername.xml to an appropriate NIB format description.
..and yeah, got the message re 'next release' for the DTD/XSD*. Cool.
For those that are .."DTD-minded", and just *cannot* wait for the files, I have put them here..XSD <http://www.javasaver.com/xss.xsd>DTD <http://www.javasaver.com/xss.dtd>
* Clarification for those who were not 'in' on that series of emails..There were two validation files intended for this release that did not quite make the build, but were mentioned in the updated hacks/config/README.
** And, yes I do have a hide, presenting a java (sucks) component for consideration for the rendering of the XSS config. files on the Macintosh. (shrugs) I'm like that.
Note that the dialog that (hopefully) appears on-screen is a development version, with a few 'quirks' to it.
In case it's not obvious, any solution to this problem that introduces a dependency on Java is profoundly uninteresting to me. In fact, my indifference to that could only be described as "sexual" in intensity.
What about the XSLT to transform the savername.xml to the XML descriptions used by the NIB files?
As far as I understand.- It is possible.- Would assist in generating a Cocoa GUI.- Would not require Java.
I can't help you with the coding, but I am more than happy to sacrifice my system to the testing effort.
I hacked this together this evening for qix. The code is a mess and shines bad light on me, but it is only a proof of concept (with lots of "errors"). I modified qix slightly to make life easier, I removed the alpha support (and assosiated util code), and the XRDB nonsense (hard wiring all configurable parameters to their default). Seeing as you abstracted out all of your XRDB calls that will make life easier.
Unfortunately, the Mac OS X screensaver messaging model is different than the Xscreensaver one. Under Mac OS X, the framework calls a function every time you are to paint, and under Xscreensaver the hack calls to the framework whenever it feels like ("once a frame"). In order to make a hack work like OS X expects it to, I used threads (really all I wanted/needed was a "context switch" a sort of longjmp that recreated the entire stack). Alternate means of adapting are more than welcome.
I used Xcode 1.5 and Mac OS X 1.3 on a Mac mini if there are incompatibilites. You can find my proof of concept at http://www.firebomb-w3c.org/lj/qix.tar.gz . Load the .xcode project file, build, and then double click on the .saver to install it. I am interested in building/maintaining a more complete shim, and am willing to adapt coding styles and take direction (I could build the shim on my own, but there is no reason for two people to be doing the same thing).
I did a couple (OK, three easy ones) as "native" OS X savers, but I didn't make any attempt to do it in a sane manner... they're basically rewrites with native UIs and the original algorithms.
If I had more time, I'd attack it from the other end (fake XLib; there's XML parsing in Cocoa already and you can build a UI programmatically). But, you know, lazy, busy, etc.
HAY HOWKUM EYE KANT LOK TEH SCREEN AS ROOT WTF LOL!!!111
Dedicated to the LazyWeb...
your "don't put the bag on your head" icon is pretty awesome. thought i'd mention it.