Blurry

Recently Surplus stopped working. Well, it hasn’t been working for a lot of people for a long time already, but that’s besides the point. It stopped working entirely. Surplus has always been a rather fragile creature. It operates like a kid on a high speed scooter attempting to carry a house of cards between two strangers. That house of cards is part of a delicate system of frames inside frames inside frames inside frames that move between frames. Surplus is this fairly atrocious mess of frames.

Framing things works out fine until you discover that whatever you’re framing is trying to break out. Meet the X-Frame-Options header, the source Surplus’s recent predicament. It has well meaning motives: to prevent Google from suffering from evil attacks like Clickjacking, XSRF and other nasty things. Incidentally, security-wise, Surplus would probably belong closer to something of that nature than a legitimate application. It doesn’t use an API because applications generally wouldn’t find it useful.

Recently, all Google properties started including that X-Frame-Options header, and now can’t be embedded in frames. It wasn’t an absolutely unprecedented move, because just a few weeks earlier Google Video had started sending out the header (which led to an update which moved from a Google Video host frame). But now it was across all Google Sites, and there was no short term hack that could be done.

The solution was to take a random Google page which didn’t send out the header and mimic all the postMessage messages that are sent from the Google Plus notifications frame. Consequently, the entire frame signaling and attachment system had to be rewritten, and that system was so deeply tied into everything else that Surplus 4 ended up being almost an entire rewrite (the inner frame actions, the options page and the notifications parser did not change).

https://chrome.google.com/webstore/detail/pfphgaimeghgekhncbkfblhdhfaiaipf

I’m porting the multitouch concept to python. Why? Because i’m on linux now, mono sucks, and PIL is pretty awesome.

I’ve set up a mock-rig where there are 2 mirrors on the side angled by erasers with a crappy Creative NX webcam mounted on a textbook over it. It seems like the only practical use of this is for a multitouch-table sort because gravity makes it otherwise pretty hard to calibrate.

So after I rewrite the software I need to try getting it to parse an actual image. Then I need to somehow hook it up to streaming webcam data, and somehow do something else.

I’ve set some tiny goals for Ajax Animator 0.21/0.22/0.23/0.24/0.25. I’m not really good with version numbers.

0.21 is mostly to work on the collaborative, online, web 2.0 aspect of it. Enabling collaboration is important, and I’m a huge supporter of User Created content (virtually all my projects are open source, and they include some entirely user-created things like my MMORPG, Project Wikify, and a few others). At one point, since the old ajax animator (not anymore) would keep logs of everything previewed (as we needed to convert it to flash to preview). I would enjoy people trying out how things were like. That was in the day where there were to tools: rectangles and sticks, and the lines didn’t tween well. Color picking was unnecessarily complicated, the tweening engine crashed every minute, and couldn’t do anything, etc. Since the 0.2 rewrite, things are much better, but I still miss having those user-management features.

If you didn’t know that, User Management/Sharing has been in the ajax animator for a while. It was frequently added, removed, mutilated, upgraded, etc. I think it was there since the DHTML Goodies days (0.08?). It got removed for a while, got added again, removed, rewritten, and now removed again. I look forward to adding it again.

I guess much of it is already there. The login should look pretty much the same as the old one, but with the whole login thing replaced with a single OpenID box and a login button. I’m not exactly sure what to do after this. I think there should be a little profile box that replaces the login panel. I’m debating whether the profile should house a list of your saved animations, or if it should be nested into that Animation browser (that actually works!). I’m leaning towards the latter. The profile may house a link to your folder in the animation directory, a button to save your edits (as with File->Save->Webserver). Etc.

With that, it would include some form of user management system. I’ve almost completely settled on OpenID because of it’s flexibility, futuristicity, freaking-awesomeness (getting a bit overboard…). I’ve just been surfing the web (Wikipedia stuff) and I’m increasingly interested in OpenID, as it seems much more “ajax-friendly” than I previously thought.

Some time, i’d like to switch to a more scalable app-engine oriented system (it’s already serving up static JS now). I’ll use my server at antimatter15.com more (Java-Enabled), so there can finally be decent flash export :)

One thing that i’d really like, that’s really probably painful, is to better support IE. There’s no problem with IE support in the general components of the Ajax Animator (Tweening/UI/Save/Format/Abstraction Layer/etc), but rendering isn’t very good. I’d like for it to be better. OnlyPaths is already great, but IE support is big for it to become mainstream. I’d like it for use in a more educational and amature(ish) setting, where people have the most use for free/opensource/easy-to-run apps. In education, many people are still using IE, and that’s a big problem.

I’ve been looking into other renderers for the future of the Ajax Animator to run on. For the forseeable future, the editor will be OnlyPaths, because it is the only one that really fits the needs of the project. But it’s built on a less-clean, prototype-like (non-namespaced) foundation, and isn’t built exactly as it should. It’s not up to me, but I think that OnlyPaths should be an editor, rather than a renderer, or at least the renderer and the editor to have very visible lines between. Right now, much of the editor interface is in the renderer. That means a lot of unnecesary work. The addTracker function is currently in the renderer, this is completely the wrong thing. It was fine in the days when it was Richdraw and the tracker was just a blue square, but that’s not scalable. On this trend, you would need 2 copies of essentially the same code (VML/SVG) for the tracker/etc. I’d much prefer to have a interactive-less renderer and addTracker function in the editor, where all the actions are calls to the drawing API. Either Onlypaths has to get a better VML renderer, or we have to switch rendering engines to something like Dojo.GFX or Raphael and port the editor over to the new renderers. I like the current OnlyPaths one a lot. It’s been developed side-by-side with the Ajax Animator, and is very well integrated. I dont like Dojo.GFX too much, because it’s dojo-dependencies, but it’s a very solid and stable framework. And Raphael isn’t as powerful as the current OnlyPaths engine yet.

I’ve not been releasing anything for a while, for several reasons:

1. I’m converting everything to the Ext UI (from textareas, tables, etc. to Ext grids, form fields) 2. I’m completely rewriting the timeline. including a host of new features much for speed. (several TIMES faster) mainly becuase it generates only 300 frames per layer by default, instead of 500, but automatically adds new frames DYNAMICALLY when more is needed. But the rewrite is sorta unstable 3. Tons of UI upgrades. A short list of changes from the top of my head are, a new login stystem (lot’s of fading effects) My Animations; list, faster animation loading. The user animation browser is completely changed-with stuff like Rating animations and comments coming. 4. Sorta goes in UI upgrades, is a new loading splash screen. It has a progress bar, showing status. And CSS is dynamically added, and loads from either the local server, or google code’s subversion (faster). 5. Cross Domain Ajax. The current ajax implementation only allows you to generate flash animations if you are on a php server with all the libraries/files installed. And sometimes you go to it from a proxy or google code beta or something. If that happens, you will not have any access to creating flash animations. So, soon it will curcumvent this restriction, by using a script tag hack, to load the animations from the server. Though the current ajax implementation will still be used for larger animations. And i might revive animation compression for this purpose. 6. Upgrading to Ext 2.0, this is not really happening NOW, but is being actively thought of. It’s not really a “painless” upgrade, with lot’s of stuff to modify/rewrite. 7. Everything has two options. One is to load from subversion, or the local server. It’s better if you load it from subversion, if you are mirroring it, or if your server is slow. And in many cases it’s really fast, and automatically gzip encodes the stuff. Great isnt it? so it has an option of loading all* (okay, most…) images and CSS from google code.

8. And even more stuff……

I’m just doing some size reduction, and ui improvement now. There has been some preliminary support for IE, and also a rewrite of the tweening engine to support lines.