Friday, July 6, 2012

Physics

As some people may have noticed, there's a new module that hit SVN recently: Physics.

Using the new ephysics library which has been written by ProFUSION workers, this module attempts, and sometimes succeeds, at applying basic physics effects to windows on the desktop.

There were a number of hurdles to making this work at all. To begin with, E17 is very particular about where windows are placed. The callback chain for simply dragging a window around is fairly extensive, and it would have been impossible to successfully add physics in. To get around that, I was forced to add a hook on literally the line prior to a window's position being updated; this callback allows a user to receive and, optionally, adjust the coordinates.

On top of this, the version of ephysics which I based the first version of the module on did not allow easy changing of velocity, so the only possibility was to add "impulses", as they are called in Physics Library World. These set initial velocities which decay over time based on friction and collisions, and are much less precise -- obviously quite a problem when working with something that we want to be precise such as moving windows around the desktop. As a result, the current physics movement is inconsistent and feels a bit clunky; I only had one chance to apply the impulse to a window, and adjusting it was impossible due to another bug:

"Boundaries" in Physics Library World are objects which exist at the edges of the world (screen) which should prevent any other object from getting past them; instead, an object will bounce off it. Unfortunately, when applying impulses repeatedly to an object it will tend to accelerate uncontrollably and rocket past these boundaries into offscreen territory, leading to lots of lost windows. I learned to enjoy the "Cleanup Windows" functionality during tests here. Eventually I decided that the best way to prevent this was to try to be less precise -- only setting the window in motion at one point based on a configurable number of drag frames.

I quickly encountered another fun feature: while windows would no longer reach escape velocity, they would actually get stuck in the screen boundaries and be immovable. More workarounds were added here to disable all physics if a window somehow moved into a screen's boundary area, and now a user can freely move them in such cases.

There's a lot of work to be done on this module, and a lot of possibilities for it, some of which I've listed in a TODO file in the module's directory on svn. Graphical effects are doable, and probably worthwhile, but the biggest thing at first is obviously going to be improving the accuracy and "feel" of the physics. Right now it's barely even a toy, but I want to be able to play Jenga with my windows!

To conclude, don't expect to get any work done running this module. Keybind moves won't trigger physics, but having your entire desktop bouncing around probably won't increase productivity by much.

PS. check out my other blog