3D and Wii: Useful Redeye!

This is a brilliant video:


Head Tracking for Desktop VR Displays using the WiiRemote

This is the effect I wanted to produce at university back in 1999 for my final year project – but no webcams had any good apis for tracking head movements (I just wanted to track heads, I didn’t think of using the wii).

The trick that Johnny is missing is that he could drop the sensor bar, and adjust the sensitivity to look for redeye reflections from your eyes (which plague all your photos).  With a bright IR source on top of the camera, the eyes should be easily findable, and the headgear wouldn’t be needed.

That would give us the headsetless 3D TV we always wanted.

Cross-domain JavaScript to Flash

Ok, what we learnt last night:

If you move your SWF onto another server (eg, using a caching server, CDN or similar), and have JavaScript in the page calling the SWF, then it will fail.

First step, we added a crossdomain.xml to the CDN server.  It made no difference, and was not requested by the SWF anyway.
Useful fact:  you can see flash requesting crossdomain.xml in Firebug.

Second step, we added “System.security.allowDomain(“http://www.xyz.com”)” to the Flash.
Useful fact:  check the “content-length” in the response headers to see when the new file has been deployed – it took more effort to deploy than expected, and this was a lifesaver as we nearly dismissed this option.

The second step worked.

Useful fact:  even though the JS files were served from the CDN too, they were executed within the page, and so were executing on a different domain to the Flash.

Useful fact:  SWFLiveconnect was irrelevant.  We already had set allowScriptAccess to always in the params.  We used ExternalInterface to make the function calls available to the JS.

Useful fact:  The Adobe docs refer to the method as HTML->SWF, not JavaScript->SWF.

Useful fact:  we tracked the problem to a definite JS->SWF issue using breakpoints in the JS using Firebug.  Brilliant.  The JS call to the Flash returned nothing – it failed silently, but stopped the function.  Correct behaviours would have been to return “undefined” and continue to the next line.

Final note:  Someone who understands HTML, CSS, JS and Flash is not your weakest tech link.  They probably know the most about the many technologies on the Internet.  So, give them some days to test before you roll out something new like this.  The architects and Java guys won’t follow it – give the HTMLers the time, as they’re on the front line.

Satchmo finally running

Woah, that wasn’t easy.

I managed to get it running using Django SVN trunk revision 8222 (pre-signals/dispatcher rewrite), and latest SVN Satchmo 1404.

It’s not easy on a PC to get the required files, got to be said.  Most of the easy_installs don’t work. 

I wasn’t sure where trml2pdf should be placed (install instructions: “put it where you want!” – thanks :-p).  I put the folder in python/site-packages, and tested with “import trml2pdf” at the python line.

Finally, all was running well and I started the shop, when I hit:
‘WSGIRequest’ object has no attribute ‘session’

This is because I used the recommended setting.py almost directly.  However, their setting-customize.py doesn’t include the “standard” stuff.  I’ve no idea why – it should have everything needed to run.  Anyway, it missed the middleware settings for the sessions.  My middleware settings now read:

MIDDLEWARE_CLASSES = (“django.middleware.locale.LocaleMiddleware”,
                      “django.middleware.common.CommonMiddleware”,
                      “django.contrib.sessions.middleware.SessionMiddleware”,
                      “django.middleware.doc.XViewMiddleware”,
                      “django.contrib.auth.middleware.AuthenticationMiddleware”,
                      “satchmo.shop.SSLMiddleware.SSLRedirect”,
                      “satchmo.recentlist.middleware.RecentProductMiddleware”)

I still have some outstanding errors for the languages.  I had to set my LANGUAGE_CODE to “us” – pretty odd, because that’s a country code.  Doh.  Plus, I want proper English (GB), and I’ll have to make sure I can do that.

I don’t know if that’s connected to the errors I got when doing:
python manage.py satchmo_load_l10n

But I ignored that and it still seems to be running 🙂

Final note:  For a Django App, that demo store is bloody ugly ;-P

Update: Site looks better now – had to set the MEDIA_URL to ‘/static/’

Satchmo: AssertionError: Signal receivers must accept keyword arguments

Sigh.

Apparently you just can’t install Satchmo as it stands. It needs the latest Django trunk, but doesn’t work with the latest changes. We need to wait for the multi-coloured-swapshop to be integrated.
http://groups.google.com/group/satchmo-users/browse_thread/thread/b871eff0685efd19

So, I just have to wait.
(I’ve tried getting the new branch, but it doesn’t run easily)

Would be nice to have a mention of this on the install docs.

Updated: Sorted. I got revision 8222 of Django out of SVN. I then had to revert the changes I made detailed in my last post.

Django + Satchmo: ImportError: cannot import name ImageField

I’m experimenting with Django for Dots Shop.  Satchmo seems to be the thing to use.

But it’s a real pain to install.  I keep getting the error:
ImportError: cannot import name ImageField

No-one on the Internet has mentioned this.  The only way I found to fix it was to search+replace in the Satchmo project for: 

from django.db.models.fields import ImageField

and replace with

from django.db.models.fields.files import ImageField

Four occurences.

I’m using SVN Django (a2), and Satchmo 0.7.