The event is put on by the Vancouver PHP user’s association, a non-profit organization that advances php development and other open source initiatives. Sign up and register today to learn about or simply promote the use of open source technology! Hope to see you all there!

It was a love-hate relationship with that machine. It had a docking station which is something that I think is missing from the Macs. Then again all I really need is just a few more USB ports so a hub will suffice. The 4:3 screen sucked, however IBM has a new version that has a wide screen so it’s a bit better. Linux was absolutely awesome – super fast, snappy response, no crashing… developing Flock was a breeze.

Windows was a whole different set of apples! The performance was absolute garbage, taking anywhere from 1-2 hours for an fbuild_all (neat little script that automatically updates subversion and builds from the root source dir). Linux was no more than 45 minutes. Now this is largely due to ccache being broken under cygwin, but even loading Thunderbird/Flock/Firefox/Pidgin/Skype makes the machine crawl. I stayed mostly in Linux because I wanted to actually get *some* work done. This created problems tho every time I booted into Windows because inevitably the tree would be so out of sync that I’d be spending a minimum of 1.5 hours just building before I could do anything. Occasionally during the build my machine would hang when it was linking large object files.

Enter the new intel Macbook Pro: As soon as I got it I immediately got my hands on a Gutsy and WinXP disc. I got my machine triple booting in probably less time than it took to do a full rebuild of Flock under my old machine. I still needed to setup the build environments on each OS, but that wouldn’t be so bad. I spend most of my time in OSX and I love it. It’s exactly what I’ve been looking for all these years – nice eye candy with standardized installation of software (read: drag program into Applications folder) and a shell to interact with. Performance of WinXP is actually better than what I was getting about of the IBM – so I’m happy there.

Having triple boot on the Mac is great – I think anyone developing cross-platform software targeting the big-3 definitely need to consider Mac.

Blogged with Flock

Tags: Mozilla, Development, Flock, Web 2.0, Firefox, Browser

1) Built-in update manager downloads and installs a custom xpi.

2) This extension will load on next start, so all we need to do is overlay the browser.xul and we’ve got startup on every instance from that moment forward. All of our intended logic is encapsulated and run with privileges inside the chrome.

3) Use the hidden window trick to limit launching of the code to once-per-session.

4) Use the “@mozilla.org/download-manager;1″ CID to initiate the download and then monitor all downloads using the observer service (watch for dl-start/dl-done etc).

5) Once that is complete, you can then call downloadedFileObject.targetFile.launch() and your installer will run!

More details will follow when I can release the code.

• build the source for xulrunner
• build python xpcom/dom into xulrunner

Step One

Checkout the client script from any directory (for these purposes i’ll say “/home/mark/development”):

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/client.mk

This will checkout the client.mk file which will be used to get the mozilla source. A new directory will be created “mozilla” and you’ll find “client.mk” inside.

Step Two

Once step one is completed, change into the mozilla directory where the client.mk file is and create a new file called “.mozconfig”. It is important to be named exactly how it sounds,dot-mozconfig. This is the configuration file that will be used to checkout the specific source code that you want (xulrunner) and build it with the appropriate flags enabled. This is mine:

ac_add_options –disable-optimize –enable-debug
mk_add_options MOZ_OBJDIR=@topsrcdir@/obj-xulrunner
mk_add_options MOZ_BUILD_PROJECTS=”xulrunner”
mk_add_options MOZ_CO_PROJECT=”xulrunner”
ac_add_app_options xulrunner –enable-application=xulrunner
ac_add_options –enable-default-toolkit=cairo-gtk2
ac_add_options –disable-javaxpcom
ac_add_options –enable-extensions=python,default
ac_add_options –enable-svg
ac_add_options –enable-xft
ac_add_options –disable-tests

Explanation of some of the key entries:

ac_add_options –enable-extensions=python,default | This tells the build script to checkout and build both the python/xpcom and python/dom code. You’re probably wondering what the difference is, and it’s pretty straightforward – python/dom is for using python instead of javascript for your xul handling; python/xpcom is to be able to embed python in an xpcom module.

ac_add_options –enable-default-toolkit=cairo-gtk2 | This is a MUST for linux-based systems. You’ll get compile errors if you don’t!

Step Three

Save the .mozconfig file and then execute:

make -f client.mk checkout

This will checkout all the xulrunner source, python source, and anything else relevant to building based on what you put in the .mozconfig file. I enabled svg just because I wanted to play around with that too Now, normally at this stage you’d go on to compiling the source but as a result of a bug you’ll need get the following patch and apply it before you start the build:

http://svn.openkomodo.com/openkomodo/view/openkomodo/trunk/mozilla/patches-new/HEAD/pyxpcom_pyxultest_make.patch?rev=132

Please read mozilla bug #392210 for detailed explanation why. The short and sweet is that the Makefile for linux screws up when trying to build the python object file.

Step Four

Time to build the source! Execute the following:

make -f client.mk build

This may take a while.

Step Five

Change into your mozilla object dir – this was set using:

mk_add_options MOZ_OBJDIR=@topsrcdir@/obj-xulrunner

In this case it will be “/home/mark/development/mozilla/obj-xulrunner/xulrunner”. Now execute the following command:

make package

You don’t really need this to do initial development but I like to do it anyways and then move the whole xulrunner package over to a working project dir so that I can run my application in it’s own space without relying on my mozilla/obj directory. This will probably take a while on your computer.

Step Six

Now you’ve successfully built xulrunner with python available for scripting! Copy the dist/xulrunner directory to your project xulrunner directory:

cp -a “/home/mark/development/mozilla/obj-xulrunner/xulrunner/dist/xulrunner” “/home/mark/development/my_cool_project/”

You’ll have a fully encapsulated “xulrunner” platform to build your first python xulrunner-based app! Hold on tho, you’re not quite done. You now need to setup some enivronment variables.

Step Seven

I put the following into a function called “env_coolproj” inside my .bashrc so that when I want to do development on this cool project, I can just execute “env_coolproj; cd $c” and it will setup all the environment variables for me nicely and cd’s me to the main application root directory. I have setup my project using subversion so I’ve followed the standard svn repository layout.

export COOL_PROJECT_DEV_DIR=/home/mark/development/my_cool_project
export PYTHONPATH=$PYTHONPATH:$COOL_PROJECT_DEV_DIR/my_cool_project/xulrunner/python MOZILLA_FIVE_HOME=$COOL_PROJECT_DEV_DIR/trunk/my_cool_project/xulrunner/
export LD_LIBRARY_PATH=$MOZILLA_FIVE_HOME
export c=$COOL_PROJECT_DEV_DIR/trunk/my_cool_project

Now you’ve got a setup ready for python development! The only thing you need to change in your xul to switch from javascript to python scripting is add the script-type=”application/x-python” to the window/page element (the first element not including the <?xml/> tags), and add <script type=”application/x-python”src=”chrome://mycoolproj/content/main.py”/> inside of that element.