Brad\’s Blog

Several people have been asking for an updated build of xulrunner for maemo.  I know the tinderbox I set up in December has been broken since mid January.  The good news is the build/release team is taking over these responsibilities and will be doing an infinitely better job than I have in maintaining it.  The first output from this bot is now available here:

ftp://ftp.mozilla.org/pub/mobile/xulrunner-1.9b5pre.en-US.linux-arm.tar.bz2

The build bot is getting very close to being able to push these builds automatically, so soon you’ll be able to find the latest and greatest here every day.  Also, once I get off my but and make the changes to the build scripts to produce debian packages from this, you’ll be able to install it from the application catalog on your n800/n810.

You’ll notice that this is xulrunner and not firefox.  There are several reasons for this, not the least of which is we hope this will encourage people to roll their own browser (and other apps).  There are already several available to try out, hear is a sampling:

Browsers:

http://wiki.mozilla.org/Image:Touchscreenbrowser-atotic.zip (from atotic)

http://wiki.mozilla.org/images/b/b1/Touchscreenbrowser.zip (from venky & co.), discussion can be found here: http://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen

http://people.mozilla.org/~blassey/SpBrowser.tgz (from me, 2 months old) discussion can be found here: http://wiki.mozilla.org/Mobile/UI/Designs/NonTouchScreen

http://benjamin.smedbergs.us/xulrunner/mybrowser-0.2.2.xulapp (from bsmedberg, very minimal)

Other:

http://people.mozilla.org/~blassey/tetris-example.tgz (tetris game I took shamelessly from croczilla)

http://benjamin.smedbergs.us/xulrunner/xulmine-0.9.xulapp (mine sweep originally by Neil Rashbrook, packaged as xul app by bsmedberg)

And there’s already a collection of apps running on xulrunner for the desktop.  Most of them are not packaged to be easily used on maemo with xulrunner.  If you’re feeling adventurous, give them a try.  If any of them work, leave a comment (maybe even a screen shot).

http://developer.mozilla.org/en/docs/XULRunner_Hall_of_Fame

and

http://developer.mozilla.org/en/docs/Category:XULRunner:Examples

Installation
This is the procedure I used to install xulrunner on my n810 (as root)

# cd /opt
# bunzip2 /home/user/MyDocs/.documents/xulrunner-1.9b5pre.en-US.linux-arm.tar.bz2
# tar -xf /home/user/MyDocs/.documents/xulrunner-1.9b5pre.en-US.linux-arm.tar
# cd xulrunner
# ./xulrunner --register-global

and then to install and run an app, I did the following (again, as root)

# cd /opt/xulrunner
# ./xulrunner --install-app /home/user/MyDocs/.documents/<application name>.xulapp
# /usr/lib/<vendor name>/<application name>/<application name>

A couple notes, I downloaded everything with microb, which puts downloads in the Documents folder and hence the path above. The vendor name and application name are specified in the application.ini file of the xul app. Finally, the –install-app flag assumes a zip archive (which is what the xulapp extension is). You may need zip the app up yourself to use it. I

I installed and ran xulmine, mybrowser and chatzilla.  They all ran (woot!).  To prove I’m not completely full off it, here’s a screen shot:

If you have your own ideas for a good xul app or what the browser should look like, put them into javascript and xul and post.  Leave a comment here so people can try them.

Note: some of these xul apps were written before mozilla 1.9 was released.  If you get a warning such as “Could not find compatible GRE between 1.8 and 1.8.0.*”, you’ll have to edit the application.ini file.  Just change MaxVersion from 1.8.0.* to 1.9.0.*

Doug blogged friday about getting winEmbed and xulrunner going in the windows mobile emulators.  We were both using the windows mobile 6 professional sdk as the target (aka Pocket PC), because that’s the configuration that was checked into svn.  Unfortunitely, those binaries did not run on the HTC s730 I have to test with, which is windows mobile 6 standard (aka smartphone).

Well with some ever so slight massaging (there functions defined in the headers of the standard sdk that don’t seem to exist in the libraries, tisk tisk m$), I finally got a build going on my phone.

First I tried a very simple xul app I wrote that contained a toolbar, button, label and browser element (src=about:mozilla):

nice, very nice.  Next I pressed my luck and tried bsmedberg’s MyBrowser. Lo and behold… it ran too. Complete with the network connection:

One last note about this.  This is a full debug build for the entire tree, with all the binary bloat that implies.  This makes me fairly optimistic that we will be able to run reliably on these types of devices.

no, really….its freakin out.

http://www.youtube.com/watch?v=FzmOpb7aRxE

Not surprisingly, it crashed after a couple minutes

I’ve been trying to figure out why the string being passed to XPCOMGlueStartup (and subsequently XPCOMGlueLoad) was “disappearing.”  Turns out it wasn’t.   My debugger just couldn’t see it.  As you can see from this screen shot, when I decided to print the content of the variable to stdout (mostly to prove to myself that I’m not going insane), it turns out that the string is there.  Visual Studio just decided to waste 3 hours of my life (thank you M$).

I want to clarify the point of this post. I am not attempting to make the point that hg is a bad tool. I am sure it is very helpful to some users. My point is that, IMHO, it does not solve an existing problem with Mozilla that justifies the inherent pain of switching from cvs to hg.

Over the last few weeks the mobile team has been using Mercurial to manage the code we’re using to build xulrunner for Windows Mobile. Up to the middle of last week it worked fine as dougt was the only one checking in patches while I was off in my own personal unicode hell.Then wednesday I finally got the code to compile with UNICODE defined. At that point I all I wanted to do was update, merge and create a diff. I’m not sure where thing went wrong, but wrong they did go.

Its almost a week later, and I still don’t have my patch. I’ve given up on that eureka moment when I suddenly discover that elusive string of commands. Instead its 3am 4am and I’m hand applying my changes to a freshly checked out working directly from our new svn repository.

All joking aside, I’d like to do a bit of a post-mortem on this. From talking to a few people at work week it seems everyone that is using hg for their work at mozilla is using it for changes they’re making to one or two modules that for the most part no one else is working on. In fact, I didn’t hear of any instances of two or more people collaborating to work on the same set of files at the same time. Granted in the version control world, this is the sort of scenario that makes us all recall late nights of hand merging conflicts, but we’ve all done it. Its boring, its tedious but we know how to do it.

With hg, I don’t know how to do it. I have received a fair amount of advice and and several suggestions from various people on the subject. In fact I want to sincerely thank jorendorff for spending upwards of an hour with dougt and I trying to sort this out. But it seems once you dig down enough the conclusion becomes, “hg wasn’t designed to do that.” That being produce patches that peers can review and can eventually be checked into a central repository that everyone can pull. What it was designed for is combining the efforts of several people who are working on very distinct modules and are publishing their changes either through patch queues or their own repository (hg serve).

Please don’t take this blog post as a bleary eyed developer slinging mud. I hope this will spark some discussion around which tools are good for which jobs. From what I’ve seen, hg is not very good for collaboration on the peer reviewed central repository model that mozilla has traditionally worked on. It does seem good for experimental work like that being done by the moz2 folks. Eventually we need to make a coherent product out of those experimentations, and I don’t see how that will happen with the current set up. Maybe I’m wrong. In fact I’m sure I’m wrong on several points (I just don’t know which ones), please point them out.

There are a few things I’m sure of. First, hg works on a model completely different to that of cvs and svn. Not only does every one using it need to get their head around that model from the beginning (admittedly, my first failing). They also need to follow some new and unique procedures. In fact a whole new set of “social” norms need to be developed (or at least published) for this tool.

Finally (and probably most importantly), in its current state hg introduces a barrier to entry for new contributers that seems entirely unnecessary.

Wow…posting those UI designs got a whole lot more attention then any one could have guessed.  I supposed people just love eye candy.  In case it wasn’t abundantly clear, these are not final designs.  In fact, these are just the first of what I hope to be many suggestions that  will be posted, debated and torn apart with criticism.  They are at present way too conservative, as I see a major opportunity to completely rethink how users interact with the web in this project.

If you have any ideas, please post them.  They can be anything from XUL examples to photoshop concept renderings to chicken scratches on a dinner napkin.  The point is to get the ideas out there for every one to discuss and build upon.

I want to point out though that the power of mozilla makes it really easy to turn these ideas into working prototypes.  Go ahead and download one of the examples.  You will quickly see that the code looks very familiar to any web hacker.  Even if you don’t fall in that category its fairly easy for some one to take chicken scratches and turn them into working prototypes.

Finally some of the coverage has speculated whether or not extensions will be included  in the finished product.  The answer is yes.  The goal is to deliver a Firefox experience on mobile devices.  This will include full support for extensions, themes and plugins. Further more, we are using an uncompromised version of the gecko rendering engine; so Mobile Firefox will render pages and run javascript exactly how desktop firefox does.

It took some doing, but it finally work. I’ve got Vista Business 64-bit, Ubuntu 7.10 and Max OS X Leopard.  I’d love to spell out a recipe for everyone try it for themselves, but I reinstalled each of them so many times I’m not sure which steps shot me in the foot and which ones patched things up.  If you do want to give it a try, first install rEFIt.  Then create three partitions on top of the rEFIt one, moving OS X to the 3rd or 4th (rEFIt requires the first and vista requires either the first or second).  Next install Vista. The 64 bit edition supports GPT and EFI, so that’s helpful.  Finally install Ubuntu on the last partition and make sure to install lilo to the MBR.

After a couple tries and reformats you should have a working system, enjoy!!

On Friday I posted a few screen shots and descriptions of my proposed user interface for non-touch screen phones.  The assumption is that these devices will have QVGA screens (240×320 pixels), a 5-way directional pad and two soft keys. The discussion page is here, please feel free to check it out and leave feed back. Also, I’ve created a firefox extension let’s you check out the work in progress.  It creates a 240×320 pixel window using the new chrome. I’ll keep that updated as I make changes, and it should get updated through the add-ons manager.

The central idea of the dialogs has been to simplify the navigation. Most dialogs and actions are accessed through the main menu which is mapped to the right softkey.  Dougt suggested combining bookmarks, history and the address bar into one unified places dialog.  I like that idea and I hope to get to it in the next week or so.

The feature I find the most intriguing is the scrolling and zooming with the virtual cursor. Currently, it works like this (or at least its supposed to):

• A virtual cursor indicates where the browser’s current focus is.  It also allows navigation of complex UI items such as drop down menus and roll overs.
• Short clicks of directional pad map into Dougt’s spatial navigation, bringing the focus to the nearest selectable element as indicated by the virtual cursor.
• Long presses of the directional pad begin smooth scrolling. Instead of jumping from link to link, the cursor moves in one direction at a steady speed.
• After a set amount of time, the page begins to zoom out. This is implemented with Firefox 3’s full page zoom feature. An intended side effect of zooming out as we scroll is that the scroll is accelerated.  It also allows the user to look ahead as they scroll at these higher speeds, similar to how a driver fixes their eyes further down the road at 65 mph than they do at 35 mph.
• The OK/Select key maps to the left click of a mouse. A key down event triggers a mouse down, a key up event triggers a mouse up event and a key press event triggers a mouse click event.
• The Left softkey maps to the right mouse button in the same way, providing access to context menus (not implemented yet).
• One item to be added to the standard context menu is begin selection. This will have the same effect of pressing an holding the mouse button.  The browser will highlight the text and other elements as the user moves the mouse until another OK/Select or left soft key press is detected.  The effect will be to allow users to select and copy text.

It should also be noted that the assumptions in the first paragraph is considered a bare minimum for functionality. We’d also like to do something useful (an hopefully intuitive) with any other controls that are available. The obvious ones are numbering menu items, using a click wheel or volume control to scroll and mapping clear, send and end call into things like back, forward and stop.

Some non intuitive ideas include mapping the number keypad onto spacial location of the screen. So for instance if there if a user wanted to go to the bottom right hand corner of the screen they could press the ‘#’ key.  Alternatively we could use those keys for fast scrolling (holding the 9 key would fast scroll down and to the right).  We could also map the number keys into the bookmark system (long pressing one navigates to google.com, 2 brings you to your blog site etc.).

But this brings up another point.  How do we determine what the “right” mix of default settings is?  And even more importantly, how do we let users customize these settings with a minimum of pain?