sharing one Mozilla source tree with Linux/WinXP VMs on Mac host OS

Here's how I shared one Mozilla source tree on my Mac OS X host OS (one Core 2 Duo, 4GB physical RAM) with two VMware Fusion VMs, one running Ubuntu Linux 8.04 (two CPUs, 1GB RAM), the other running Windows XP (one CPU, 512MB RAM):

I checked out the source tree to ~/Mozilla/source on my Mac's filesystem.

I configured each VM with one shared folder via Fusion's Virtual Machine > Shared Folders > Shared Folder Settings... configuration dialog. In both cases, I shared my Mac user account's home folder (/Users/myk). Fusion 2 named both shares myk (Fusion 1 had named the Windows share myk On My Mac).

I made these shares read/write so I could manipulate the tree from the VMs (particularly from the Linux one, where I do most of my development) and also because the Mozilla build process tries to modify the source tree, even when you're using an objdir (f.e. bug 384978), and the build process runs smoother if you let it.

On Linux, the shared folder showed up at /mnt/hgfs/myk. Because of a limitation in Fusion (described in the release notes as "Shared Folders permissions might be too restrictive in Linux and Mac OS X Server guests"), I had to configure the /etc/fstab entry for the shared folder to mount with my Linux user account's uid/gid:

# Beginning of the block added by the VMware software
.host:/   /mnt/hgfs   vmhgfs   defaults,ttl=5,uid=myk,gid=myk   0 0
# End of the block added by the VMware software

Note: this modification gets reset and has to be redone every time I reinstall VMWare Tools (i.e. after each kernel upgrade).

On Windows, the shared folder showed up at Start > My Network Places > Shared Folders on .host. Fusion 2 automatically created a network drive for the shared folder, mapping it to the uppercase drive letter Z:. When I was using Fusion 1, I manually created the network drive via Tools > Map Network Drive in Windows Explorer.

In older build environments, I then had to create /etc/fstab (following the instructions in /etc/fstab.sample) to mount the network drive, but I think simply mapping the drive automagically makes it available at its lowercase Unixy equivalent (f.e. /z) in the latest versions of MozillaBuild (perhaps after a MozillaBuild or Windows restart?).

I only share my source tree, putting config files in ~/Mozilla/configs and builds in ~/Mozilla/builds on the Mac and Linux filesystems and in /home/myk/Mozilla/(configs|builds) on the Windows filesystem (as my home directory on Windows is /c/Documents and Settings/myk, and Mozilla has trouble building to a directory with spaces in its path).

Once configured as described, building on each OS became the simple matter of crafting the build config file, changing to the source directory, and calling make, for example on Linux (with this config file):

cd /mnt/hgfs/myk/Mozilla/source
time MOZCONFIG=~/Mozilla/configs/minefield-opt make -f client.mk build

On Mac (with this config file):

cd ~/Mozilla/source
time MOZCONFIG=~/Mozilla/configs/minefield-opt make -f client.mk build

And on Windows (with this config file):

cd /z/myk/Mozilla/source
time MOZCONFIG=/home/myk/Mozilla/configs/minefield-opt make -f client.mk build

Note: compiling on Linux seems pretty speedy, but compiling on Windows is dog slow, perhaps even slower in Fusion 2 than in 1. I haven't tried it lately, but it might be faster to share the tree with Windows using SMB.

Note: it's theoretically possible to compile on two or all three OSes simultaneously, but it does slow down the machine, and I got build failures the few times I tried it (I don't remember exactly what now, I think something about the Windows build process being unable to access certain files).

Rocking the Linux User Experience (Boat)

Mark Shuttleworth has recently announced plans to rock the Linux user experience (yes, I know I'm a week late; I've been on vacation and am just now catching up).

I've been an avid Linux user for about a dozen years, first on Red Hat, then Fedora, and lately Ubuntu, and I've had my share of frustrations with the OS, so I'm thrilled to hear about this initiative.

And I have a piece of advice: don't be afraid to cross (and dissolve) boundaries between layers of functionality and give developers the authority to fix problems no matter where they reside, even at the risk of ruffling feathers (as did ZFS with its "damn the software stack, full speed ahead to the desired outcome" approach).

I say this because my small window into the GNOME development process (bugs 482354 and 162726) suggests its developers spend way too much time trying to figure out which of the many layers of functionality in the Linux desktop is responsible for an issue (and thus who is responsible for fixing it).

Mozilla isn't perfect in this regard either, but when it works well, it's because developers take responsibility for making the user experience great no matter what part of the code needs to be touched (like the recent progress being made in bug 248970 by Ehsan Akhgari in collaboration with others on a private browsing mode for Firefox).

If you want to rock the Linux user experience, be willing to rock its boat as well.

Alt/Cmd+Left/RightArrow brainsprinkling

Recently some folks have been blogging about Ctrl+Tab. It's great to see that shortcut getting love, and it reminds me that there's another one for navigating between pages that could use similar attention: Alt/Cmd+Left/RightArrow for going backwards and forwards through history within a tab.

Like the old Ctrl+Tab implementation, Alt/Cmd+Left/RightArrow only lets you move one page at a time, and you can't see where you're going until you get there. And sometimes you land on a page that is the product of a POST request, which you don't know until you are forced by a modal dialog to decide whether or not to resubmit data that you don't get to see when making the decision.

We could enable multi-page moves by making the shortcuts work similarly to Alt+Tab in operating systems: holding down the Alt key and pressing a horizontal arrow key would bring up a list of icons representing the pages in the history (perhaps formatted like Alt+Tab in operating systems or via the 3D effect Jono suggested for Ctrl+Tab).

Each icon would be a screenshot of the page as it was when you left it, and the adjacent page to the current page would be selected by default. But as long as you held down the Alt key, the list of pages would stay on the screen, and pressing the arrow keys would let you travel back and forth through it. Once you let go of the Alt key, Firefox would switch to the page that was selected at the time.

This behavior might also reduce frustrating clicks on posted pages, although the better solution, as Dan Mills recently pointed out in a conversation, would be to stop forcing users to reload pages just to go back (or forward) to them, even if they were the result of a POST.

But if we can't do that for some important technical reason, we could at least display a non-interactive and suitably-dressed snapshot of the page and drop down a non-modal notification bar at the top of the tab explaining why we can't provide the page itself and allowing the user to see what they are potentially going to reload.

And the list of pages could itself indicate which of its pages are POSTed, thus providing the user two levels of useful indication of what will happen when they try to go back to that page.

Of course, there's more to history than the past and future of each individual tab, and pan-tabscape history navigation affordances would also be useful to think through. But there's still a place for a tab-specific interface, given that many such trails represent a specific path through the web with relevance and meaning to the user, so it'd be good to improve the way Alt/Cmd+Left/RightArrow works (or invent even better tab history traversal).

Thoughts?

A couple weeks ago I blogged about my priorities for the next version of Snowl. I've just uploaded a preview release of the next version to addons.mozilla.org with an initial implementation of a view optimized for short messages and recent updates:

The view is implemented as a sidebar that shows short messages (such as from Twitter) in their entirety and displays the subjects of long messages with links to their content. Messages are sorted in the order received, with the most recent ones on top, to make it easy to see the newest stuff at a glance.

Plans

There's still plenty of functionality yet to be implemented in the sidebar, including:

• grouping messages by time period (this morning, yesterday, last week, etc.);
• making it possible to see some of the content of long messages;
• an easier way to open and close the sidebar (f.e. a button that toggles it on and off).

I also want to improve elements of the visual design. In particular, I'd like to add a subtle but noticeable visual cue that messages have arrived (f.e. making messages slide into place from the top of the sidebar).

And I'm still working on implementing message sending and conversations as first-class objects for version 0.2. This preview release is just a taste of the first of several upcoming features.

Other Changes

This release also fixes a number of bugs and makes some improvements to the architecture (there seems to be a neverending supply of such infrastructure work, but it's all necessary to prototype features on top of). And it improves access to Snowl's features via some conventional extension integration points: an item in the Tools menu, an icon on the statusbar.

Get Snowl for Firefox

Get the initial prototype: Snowl for Firefox.

Warning: the initial prototype is a primitive implementation with many bugs, and subsequent versions will include changes that break functionality and delete all your messages, making you start over from scratch.

Get Involved

Let us know what you think by posting in the forum, reporting bugs, or conversing with us in the #labs channel on irc.mozilla.org. Or check out the source and submit your bug fixes and enhancements.