XUL/web-but-post-web-frameworks are pretty cool, so I've written some demo's demonstrating how chandler could use them. Please note these are pretty much bare GUI's, and have none of the detail & work needed for a real application. This page documents how to get and run 3 pieces of a rather scattershot demo:

1) SVG Calendar
2) Chanzilla XUL mockup (written by Alec)
3) My ugly hacked-up chanzilla that connects to Chandler's repository; also contains the SVG calendar for kicks.

You can play with (1) and (2) easily, but (3) is complicated to get running. Since they're so long, notes for (3) are last on this page.

SVG Calendar demo

This is just javascript+svg+html+xul. It works with official builds of Deer Park Alpha 2 (the current alpha for Firefox 1.5: http://www.mozilla.org/projects/firefox/) You can download the Deer Park binary on any platform, then just navigate to the page http://svn.osafoundation.org/sandbox/brendano/svgcal.xml

Windows performance is significantly better than mac or linux, so use it if possible.

Chanzilla mockup (no pyxpcom)

This is Alec's work: a XUL mockup that looks just like the current chandler interface. It's packaged as a firefox extension, and works with firefox 1.0 . Warning, you probably need to uninstall it before trying to run chanzilla+repo.

Install with this link: http://svn.osafoundation.org/sandbox/brendano/chanzilla-alecf/chanzilla.xpi . Some of the text & icons aren't appearing for me at the moment so i hope i didn't screw it up.

It's also packaged so that it can be run from xulrunner; see the application.ini file for that. The unzipped source can be seen in http://svn.osafoundation.org/sandbox/brendano/chanzilla-alecf/

My observations on XUL and Python

PyXPCOM^? is a neat technology, but trying to use it to program XUL is messy and sometimes awkward. This should all get much cleaner with Mark Hammond doing python+mozilla work -- for example, integrating in python as a first-class DOM language, so you can embed it everywhere javascript is currently used in XUL, and eliminate the javascript layer entirely. PyXPCOM^? currently is a bit too loosely coupled to do gui programming very easily; that's why luke matkinson wrote some of dom->js->py utilities like js->py event dispatchers and such (he gave them to me and they're thrown in chanzilla-withpy). I'm sure the activestate products that are programmed in pyxpcom (komodo) have something similar. Most of the gui logic in the chanzilla+repo demo is written in javascript because it was easier than python ... hopefully that'll change soon!

I must say, XUL is a terrific framework to program in. It's incredibly well documented at www.xulplanet.com, www.w3.org, and you even get help from the gazillions of CSS/HTML documentation sites on the net. It knows how to be dynamic, no confusing segfaults due to things being unrendered that don't expect it and such. Tweak/reload is a great development cycle to use -- it enables experimentation to learn API's and what the system can and can't do, in the best tradition of dynamic languages. The event system makes sense. SVG support is promising, and work is being done on hardware rendering through cairo. Even if you don't have SVG, dynamic HTML+XUL can do lots of useful things that old generation desktop frameworks can't (e.g. animated expand/collapse, floating elements). The consistent DOM API for XUL, HTML, and SVG is great, despite its occasional clunkiness. Everything knows how to float, reposition, disappear and reappear, etc. And the DOM inspector is a very useful tool that could potentially be expanded into a full-out GUI builder. When the python bindings are up to speed and the build issues resolved, python+xul looks like an excellent system to program with, though lots of architecture work would have to be done.

Links:

• On making python a 1st-class XUL language: http://wiki.mozilla.org/Breaking_the_grip_JS_has_on_the_DOM
  • News: http://weblogs.mozillazine.org/roadmap/archives/008865.html
• Mozilla SVG site: http://www.mozilla.org/projects/svg/ . Here's a good overview of where the implementation is going: http://www.mozillazine.org/talkback.html?article=7176
• Philippe's document: http://wiki.osafoundation.org/pub/Journal/PhilippeBossutNotes/TheFrameworkIssue.htm

---

now the fun stuff...

Chanzilla with repo (via pyxpcom)

This bridges chanzilla to the chandler repository & libraries (e.g. like headless.py) via pyxpcom, the python server/client bindings to mozilla's xpcom interface/component system.

The pyxpcom build process is currently a bit screwy, and getting it to play nice with chandler's python is also screwy, and combined with the general screwiness of mozilla builds, it's all just nuts. I only got it working on Mac.

Therefore, no xpi firefox extension is available.

Download my hacky mac build

Untar these two source/build tarballs into /Users/osaf . They take a few gigs when untarred. Unfortunately I never figured out the mozilla binary packaging process, so it's quite the mess. Many symlinks are coded to absolute paths, so you're forced to use /Users/osaf in your path ... sorry.

they're at http://leilani.osafoundation.org/~brendano/chanzilla-withpy-tarballs

set CHANDLERHOME and CHANDLERBIN to /Users/osaf/chandler-trunk/chandler

Run chandler to get a repository, and generate some data. (this is from pre-setbranch-merge land, where "Generate Data" is really slow, but it works eventually.)

Launch firefox via

% cd 2/mozilla/od3/dist/DeerParkDebug.app/Contents/MacOS/
% ./chandler-paths.sh ./firefox

To actually open up chanzilla, go to chrome://chanzilla/content/go.html , or if you want it inside the browser window, use chrome://chanzilla/content/chanzilla.xul .

To skip the slow steps of running the chandler headless/backend, start via "FAKEDATA=1 ./chandler-paths.sh ./firefox"

building it yourself

Linux

I tried for a very long time to get this to work but it never did. There's strange issues with how chandler's python is built, and mozilla segfaults at startup.

Windows

I never tried, but I suspect this would be easier. Alec got the commandline javascript shell (./xpcshell) to load a pyxpcom component and access the repository. But he couldn't get the firefox gui to run, but I bet that's due to non-pyxpcom, non-chandler issues (possibility: he was using the free microsoft compiler instead of msvs.net, but that has issues apparently)

See: PyXPCOMExperiments

Mac

Xulrunner has some weird packaging bug on mac. I got both seamonkey and firefox to work though.

I have some more notes at PyXPCOMBrendan but everything you want should be here.

Build Chandler

You gotta do a full chandler build, because you need to patch the config for chandler's python, which means all the libraries that link to python have to be rebuilt too (i think).

The patch is attached to here: https://bugzilla.osafoundation.org/show_bug.cgi?id=3793

Checkout

Check out the mozilla source tree, using the instructions from http://www.mozilla.org/build/ . There's lots of dependencies you need to install.

I used the following ~/.mozconfig:

mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-application=browser
## . $topsrcdir/browser/config/mozconfig  ###irrelevant
ac_add_options --enable-debug
ac_add_options --disable-tests
ac_add_options --enable-optimize='-O1'
ac_add_options --enable-svg
ac_add_options --enable-canvas
ac_add_options --enable-extensions=default,python/xpcom

#seems to be ignored.  use PYTHON env instead.
#ac_add_options --with-python=/var/brendano/trunk-build/chandler/release/bin/python
export PYTHON=/Users/osaf/chandler-trunk/chandler/debug/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/od3

note that the -O1 is deathly necessary for a mac firefox build (?!: https://bugzilla.mozilla.org/show_bug.cgi?id=305827 ). Asking lots on #developer at irc.mozilla.org was the only way I got this really running..

Patch PyXPCOM^? source

PyXPCOM^? lives within the mozilla source tree, at mozilla/extensions/python/xpcom

You no longer need to patch! Hooray! (I had to apply patches from http://bugzilla.mozilla.org/show_bug.cgi?id=297598)

Configure

The mozilla build instructions say once you've done "client.mk checkout" to go straight to the full "make -f client.mk build". do NOT do that. Instead, first run "make -f client.mk configure" which will only do the configure step. Unfortunately, it doesn't set up the python paths quite right, so you have to hack the generated OBJ_DIR/config/autoconf.mk -- most importantly for the PYTHON_LIBS paths. It's probably possible to just set these in ~/.mozconfig.

--- autoconf.mk.orig    2005-08-24 10:23:06.000000000 -0700
+++ autoconf.mk 2005-08-24 10:23:42.000000000 -0700
@@ -529,8 +529,8 @@
 #python options
 PYTHON = /Users/osaf/chandler-trunk/chandler/debug/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python
 PYTHON_PREFIX = /Users/osaf/chandler-trunk/external/debug/Library/Frameworks/Python.framework/Versions/2.4
-PYTHON_INCLUDES = -I/Users/osaf/chandler-trunk/external/debug/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4
-PYTHON_LIBS = -L -lpython2.4
+PYTHON_INCLUDES = -I/Users/osaf/chandler-trunk/chandler/debug/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4
+PYTHON_LIBS = -F/Users/osaf/chandler-trunk/chandler/debug/Library/Frameworks -framework Python
 PYTHON_DEBUG_SUFFIX = 
 PYTHON_DLL_SUFFIX = .dylib
 PYTHON_VER_DOTTED = 2.4

If it refuses to get the paths right, but compiles anyway, check to see what's going on with "otool". You can use install_name_tool to fix it on the pyxpcom dylib's. Use

install_name_tool -change

to get lib_xpcom.dylib (= _xpcom.so) and libpyloader.dylib to link to chandler's {release,debug}/Library/Frameworks/Python.framework/Python .

ActiveState^?-ers currently do this for their os x komodo, so don't feel bad.

Build

Now proceed with "make -f client.mk build"

Once it's done, there's this weird duplication of dist/bin vs. dist/DeerParkDebug.app. You can run out of either, i think, but there's weird issues sometimes when using bin/.

Launch with:

cd OBJDIR/dist/DeerParkDebug.app/Contents/MacOS
./firefox

Get Chanzilla in the chrome and components

Deer Park is being all buggy and refusing to install extensions for me, so I had to manually patch in chanzilla to the chrome/ directories, as well as the pyxpcom chandler/repo connector component. This is the drudgery that xpinstall & firefox's extension system is supposed to handle. I may have forgotten a few steps here.

Let MOZDIR be shorthand for OBJDIR/dist/DeerParkDebug.app/Contents/MacOS.

Checkout the chanzilla-withpy chrome & components dir from my sandbox.

svn co http://svn.osafoundation.org/sandbox/brendano/chanzilla-withpy chanzilla-withpy

Then you have to copy a bunch of files into firefox's appdir.

cp -r chanzilla-withpy/components/* MOZDIR/components (for .py, .xpt, .idl files)
cp -r chanzilla-withpy/chrome/* MOZDIR/chrome/chanzilla (for .xul, .xml, .html, .css, etc. files)

MOZDIR/chrome/chromelist.txt needs a few more lines. I added these few, then everything started magically working. I think the issue is to coax it into reading the content.rdf's, but someone else surely knows better than me.

chanzilla:content:chanzilla.xul (chanzilla/content/chanzilla/chanzilla.xul)
chanzilla:skin:* (chanzilla/skin/classic/chanzilla/chanzilla.css)

Note that lots of the files in chanzilla-withpy/{chrome,components} are unnecessary test scripts and such; a number of js <-> py bridging utilities by luke matkinson (lukem on #pyxpcom at irc.mozilla.org) are nifty but i didn't end up using them for the chanzilla+repo thing. I threw them all in just in case I forgot about something.

tweaking & registering components

Hopefully you don't need to do this step. But if you ever tweak chandler.idl you'll need to do regenerate chandler.xpt.

cd MOZDIR/components
../xpidl -m typelib -I../../../../idl chandler.idl

Note that if you tweak a .py inside components/, you need to restart mozilla to get the changes, it has no module reloading facility.

Sometimes you need to run ./regxpcom, though i think firefox is good about running this on its own at startup.

If you tweak any chrome/, it'll show up in the reload, but ONLY if you add this line to your ~/Library/Application Support/Firefox/Profiles/PROFILEID/prefs.js (only add when firefox is NOT running):

user_pref("nglayout.debug.disable_xul_cache", true);

If you get sick of waiting for the chandler import & repo opening at each restart, set the env var: FAKEDATA=1, then the chandler pyxpcom component will fake data for the summary view instead.

-- BrendanOConnor - 25 Aug 2005