I had the Idea of Using Javascript Instead

The Genetic Wallpapers project is supposed to be able to help any artist create a wallpaper capable of shifting and moving over time to produce interesting and unique results over time.

The Idea

The problem is that artists have all sorts of crazy ideas about what and how the wallpaper should progress and currently the logic for how the wallpaper will mutate is contained within the python code of the main project.

So I had this crazy idea, what if I could move that logic to javascript, a language which far more people know and each logic mechanism would be self contained within the svg wallpaper it’s supposed to effect.

I thought this was such a cool idea I rushed to google to do a search to find out how I could execute self contained javascript from python without a browser (because it’s svg, not html) and it only needs to be able to modify the Document Object Model to move and resize the objects in the image.

The Problem

All of the projects I encountered searching for a solution couldn’t really do the job. Either they were hacks, tied to web browsers, didn’t really work or were mostly converters to make javascript out of python. Which isn’t what we need for this to work. I looked at python-jswebkit, python-spidermonkey and pyv8, none of which could really do the job of running javascript to act on a DOM.

Possible Solution

Instead of trying to use python, I could farm it out to perl. I hear perl has better javascript execution support and best of all, documentation to show you how to do it.

The alternative is to ask the community. But this is quite a highly specialised bit of functionality, very rarely do we need to run one bit of JIT code on another. But any ideas would be very welcome.

Comments and thoughts on the idea and the direction, please to post below.

26 thoughts on “I had the Idea of Using Javascript Instead

  1. PyJavaScriptCore (http://launchpad.net/pyjavascriptcore) seems like a possible candidate. It can expose Python objects to JavaScript, so you should be able to do something along the lines of passing a python xml.dom.Document object to a JavaScript function.

    (it’s similar to python-jswebkit, except that you can create a javascriptcore.JSContext without needing a pointer to an existing JSContextRef)

  2. It wasn’t a Direct X hack. It was a feature of IE 4.x, called Active Desktop. You could set your background to any specially designed web page with it, and have animations, and interactivity. As well as the common “dashboard” widget things lots of things have now.

  3. I think Rodney is talking about Active Desktop, which is the early ancestor of embedding HTML/javascript content to your desktop, in windows 95-98. It was regarded as a resource hog and a security hole of epic proportions because it allowed to use “weblike” exploits using HTML/javascript.
    http://en.wikipedia.org/wiki/Active_Desktop <- Note the "creating original wallpapers" line in there.

    However this is fairly different. Using a dedicated, local javascript library is not the same as using the whole browser engine as Active Desktop did (A feature that could be exploited by having a website modify your desktop to point to a file with weaponized ActiveX code).

    However, is it really true that javascript is used over python? Sounds a bit hard to believe, a desktop programmer is more likely (or at least used to be) to use python instead of javascript. Javascript out of the browser feels relatively new.
    Unless your intention is to target web developers who are transitioning to desktop development.
    Not confronting you about it, just would like to know if that's the case.

  4. Why even bother with a language to run Javascript? Can’t you do everything directly in JS?

    After all, some people write full desktop shells in Javascript. 😛

  5. The security issues with Active Desktop were all because it was IE, and had nothing to do with the general idea itself.

    With that said, I don’t much see the point of yet another thing to do animated backgrounds. If you’re doing it in gnome at least, the only way to do it really is to change the background image in an automated program, and that can be slow, and won’t result in smooth animations.

    KDE might be better about it, but not sure.

  6. Dobey – The idea is not to have animated backgrounds, it’s to have backgrounds that move and shift and become unique over long periods of time. Months, or an entire Ubuntu cycle.

  7. Animation is animation, even if it takes a very long time. You want smooth, gradual changes, and not to just randomly change it while the user is logged in. What you want is animated background, with extremely slow framerate. Otherwise you would just use a background randomizer, and make it significantly less random. Or you change the default background in the packaging a lot more often.

    Those last two don’t seem to quite describe what you’re looking for though.

  8. Dobey – Have you seen the videos about the functionality? This animation potential of the gnome desktop background is probably about 5 frames a minute for a png and about 1 frame per minute for a complex svg.

  9. Right. So I don’t think that’s ideal to what most people would want. It seems to me, that something which would mimic the speed at which the stars “move” through the night sky, would be closer to what people would find interesting. Something that if you’re sitting there and it’s constantly changing, but only very slightly each time, you won’t necessarily notice it, unless you sit there for several hours.

    Just taking an existing wallpaper that was designed to look a certain way, and moving the elements in the SVG to other random points, may very likely end up with a very ugly background in a few days (assuming changed once nightly). The background itself would need to be designed in such a way, that some of the elements within it, could be fluid.

  10. I agree that an animated background would be more flash, and hell with unity requiring a 3d card setup, maybe it’s time to visit that with a paid developer. but for this project, it’s out of scope.

    This project is a lot more subtle, the user is not supposed to notice for weeks, or perhaps a few days. Perhaps not as flash, but it’s also not as distracting.

    If you look (If I remember the video I linked) there are predefined patterns encoded in which kick off at certain times. The whole idea of the javascript move was to allow non-random code to do interesting things.

  11. My point isn’t about making it flashier. My point is about doing it the right way.

    I understand that the way things currently work, kind of suck. It works much better in E17 though, which has a defined format for doing animated backgrounds exactly like this, already.

  12. Do you know how it works? If it’s no SVG, I think it can not be the same project. Because I don’t know of any other tech that would do this kind of thing well enough.

  13. I think Enlightenment uses a special container format, which has a bunch of PNGs and a description of how to do the animation. I don’t see what the file format has to do with it though. Lots of things other than SVG do this sort of thing well enough. I’m pretty sure the Android feature doesn’t use SVG either.

    This is what some of the wallpapers for E17 look like, that do animation:
    http://www.youtube.com/watch?v=Zw7keAqdrpM

  14. Dobey: That looks like an interesting hack, but untimely they’ve implemented a new proprietary format unnecessarily. In any case what they demonstrate is animation, not mutation or migration.

    I get the feeling that you’ve still not understood what the project attempts to do. Either that or you are asking difficult questions simply to be difficult with me.

  15. I understand what you’re trying to do. The problem is that you’re just doing animation, but you’re trying to make it a lot more complex than it actually is. Looking at the source for your project, the way it works is that there is the original SVG, and a file with a set of transforms to be performed on that SVG. Then you apply those transforms, write out a new SVG file somewhere, and set it as the background. And to define the time between frames, you presumably run it in a cron job or similar. It is a very complex solution, but it is still a simple animation in the end.

    But I think what you *want* to do, is a lot more complex than that, but you are looking at it from the wrong direction. And “Genetic” is perhaps not an apt description of what it is you want.

    What it seems like you want, is Animated SVG (which, can be done with SMIL or ECMAScript). You would draw an abstract background I presume, with several objects on top of it, and then define in the SVG/SMIL/ECMAScript somehow, how all those objects interact with each other. Mostly, you want to define properties on the objects themselves, and have some formulae in the scripting, to control their movement and interactivity. Some basic astrophysics and particle physics, could help figure out some interesting formulae. But with very simple transforms like this, you’re going to be limited in what you can do, that will look nice. Which is why properly smooth animation is, I believe, the way to do this right. Then you can bring in some fluid dynamics into the process, and get some rather nice effects to happen.

    http://en.wikipedia.org/wiki/SVG_animation

    But what do I know. I’m just a dumb software engineer.

  16. @dobey – You’re certainly not sumb, what we have is a difference of opinion on appropriateness of the solution to a given problem. Looking at tit from a different angle is correct.

    Correct SMIL or js animation would require a new gnome svg engine, a spare 2 man years of development work by my reckoning.

    I’ve done SMIL and js animations before, they’re quire fun and I hope one day to implement the inkscape SMIL animator functionality that we’ve been talking about for years.

  17. I am just tired of having to fix all the broken tech every time I want to go write some really cool application. Would be nice if other people would push to fix it too, rather than just working around the brokenness, and delivering up poorer user experiences. But alas.

  18. Dobey: In this case reality is shockingly bad for this functionality. There is simply no way to do what you propose in any reasonable time period. I defer to the laws of physics, QED.

  19. It could be done reasonably quickly. I don’t see what the laws of physics have to do with anything. I mean, aside from the fact that your software should be based on them. ∎

Comments are closed.