Archive for May, 2015

Thanks to Lee Salzman, the state of GTK+3 support in Firefox got better. Unit tests went from looking like this:

To looking like this:

There's obviously some work left to make those look even better, but we've come a long way.

Ludovic Hirlimann recently asked if there were builds to dogfood and that prompted me to attempt making the builds from the elm branch auto-update. Which, after several attempts, I managed to get working with gross (but small) hacks of the build system.

So here we are, if you want to dogfood GTK+3 Firefox, here is what you can do::

• In a normal Linux nightly, go to about:config and create the following string preferences (right-click, New, String):
  • "app.update.url.override" with the value "https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/elm-linux/latest/update.xml" for 32-bits builds, or "https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/elm-linux64/latest/update.xml" for 64-bits builds,
  • "app.update.certs.3.issuerName" with the value "CN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=US",
  • "app.update.certs.3.commonName" with the value "ftp.mozilla.org".
• Open the burger menu, click the "?" icon, then choose "About Nightly". This should check for an update, find one, and download it. This will upgrade to a GTK+3 build.

Alternatively, you can just download and install the elm builds directly (32-bits, 64-bits).

If for some reason, you want to go back to a normal GTK+2 nightly, go to about:config, find the "app.update.url.override" preference and set it to an empty value. Triggering the update from "About Nightly" won't, however, work until the next nightly is available, so give it a day.

As mentioned in my previous post about GTK+3, if you're interested in making those builds work better, you are welcome to help:

• check the Gtk+ 3 tracking bug and its dependencies for a list of known issues or improvements to be made.
• file bugs for discrepancies you'd find between the GTK+3 and GTK+2 builds, or bugs you find in the GTK+3 build, and make them block the Gtk+ 3 tracking bug.
• check the treeherder oranges and reds on the elm branch, file bugs for them (I think at this point none are filed), or, better, fix them.
• and if you have level 1 commit access, you can test patches on the Try server, provided you pull from the elm branch or apply this patch on top of the tree you push there.

Gnome Shell, besides providing the main user interface for GNOME 3, is a Javascript shell with bindings to many native interfaces that allow e.g. Window manipulation, graphics rendering and animations, compositing, etc. It also allows developers to write extensions changing Gnome Shell's behavior.

Less known is that it is possible to replace the entire Javascript code base that Gnome Shell uses. It can be useful to hack on Gnome Shell itself (no need to fiddle with system files, or, since 3.12, no need to rebuild libgnome-shell.so), but it can also be used to implement a completely new User Interface in Javascript.

I'm starting to experiment with the latter, because I want to try building a window manager that fits my needs, while keeping away the boring details of EWMH, xinerama, and other X11 things. And because it's fun.

But baby steps, first: let's bootstrap a Hello world with Gnome shell.

• Create a directory that will hold your code.
• In that directory, create a ui subdirectory.
• In that ui directory, create a environment.js file, with the following contents:
  

  const Shell = imports.gi.Shell;
  
  function init() {
    window.global = Shell.Global.get();
  }
  

• In the same directory, create a main.js file, with the following contents:
  

  const St = imports.gi.St;
  
  function start() {
    let text = new St.Label({ text: "Hello, world!" });
    global.stage.add_actor(text);
    global.stage.show();
  }
  

• Run Gnome Shell with your code:
  

  $ GNOME_SHELL_JS=/path/to/parent/of/ui gnome-shell
  

  You may want to run this in a separate X server (I use Xephyr)

I tested this with Gnome Shell 3.14. Trying various older versions, I got different results for reasons I don't know. 3.4 doesn't display anything unless, paradoxically, global.stage.show() is removed, and 3.8 doesn't display anything no matter what.

I guess the next step is to go through some Clutter tutorials and transpose them to Javascript.

Update: On the other hand, a lot of the window managing is still done by mutter under the hood, which doesn't leave a lot of space for something really different.

[Update: An up-to-date version of this document is available on the git-cinnabar wiki]

The next branch of git-cinnabar now has minimal support for grafting, enough to allow to graft a clone of gecko-dev to mozilla-central and other Mozilla branches. This will be available in version 0.3 (which I don't expect to release before June), but if you are interested, you can already try it.

There are two ways you can work with gecko-dev and git-cinnabar.

Switching to git-cinnabar

This is the recommended setup.

There are several reasons one would want to start from gecko-dev instead of a fresh clone of mozilla-central. One is to get the full history from before Mozilla switched to Mercurial, which gecko-dev contains. Another is if you already have a gecko-dev clone with local branches, where rebasing against a fresh clone would not be very convenient (but not impossible).

The idea here is to use gecko-dev as a start point, and from there on, use cinnabar to pull and push from/to Mercurial. The main caveat is that new commits pulled from Mercurial after this will not have the same SHA-1s as those on gecko-dev. Only the commits until the switch will. This also means different people grafting gecko-dev at different moments will have different SHA-1s for new commits. Eventually, I hope we can switch gecko-dev itself to use git-cinnabar instead of hg-git, which would solve this issue.

Assuming you already have a gecko-dev clone, and git-cinnabar next installed:

• Change the remote URL:
  

  $ git remote set-url origin hg::https://hg.mozilla.org/mozilla-central

  (replace origin with the remote name for gecko-dev if it's not origin)

• Add other mercurial repositories you want to track as well:
  

  $ git remote add inbound hg::https://hg.mozilla.org/integration/mozilla-inbound
  $ git remote add aurora hg::https://hg.mozilla.org/releases/mozilla-aurora
  (...)

• Pull with grafting enabled:
  

  $ git -c cinnabar.graft=true -c cinnabar.graft-refs=refs/remotes/origin/* remote update

  (replace origin with the remote name for gecko-dev if it's not origin)

• Finish the setup by setting push urls for all those remotes:
  

  $ git remote set-url --push origin hg::ssh://hg.mozilla.org/mozilla-central
  $ git remote set-url --push inbound hg::ssh://hg.mozilla.org/integration/mozilla-inbound
  $ git remote set-url --push aurora hg::ssh://hg.mozilla.org/releases/mozilla-aurora
  (...)

Now, you're mostly done setting things up. Check out my git workflow for Gecko development for how to work from there.

Following gecko-dev

This setup allows to keep pulling from gecko-dev and thus keep the same SHA-1s. It relies on everything pulled from Mercurial existing in gecko-dev, which makes it cumbersome, which is why I don't recommend using it. For instance, you may end up pulling from Mercurial before the server-side mirroring made things available in gecko-dev, and that will fail. Some commands such as git pull --rebase will require you to ensure gecko-dev is up-to-date first (that makes winning push races essentially impossible). And more importantly, in some cases, what you push to Mercurial won't have the same commit SHA-1 in gecko-dev, so you'll have to manually deal with that (fortunately, it most cases, this shouldn't happen).

Assuming you already have a gecko-dev clone, and git-cinnabar next installed:

• Add a remote for all mercurial repositories you want to track:
  

  $ git remote add central hg::https://hg.mozilla.org/mozilla-central
  $ git remote add inbound hg::https://hg.mozilla.org/integration/mozilla-inbound
  $ git remote add aurora hg::https://hg.mozilla.org/releases/mozilla-aurora
  (...)

• For each of those remotes, set a push url:
  

  $ git remote set-url --push origin hg::ssh://hg.mozilla.org/mozilla-central
  $ git remote set-url --push inbound hg::ssh://hg.mozilla.org/integration/mozilla-inbound
  $ git remote set-url --push aurora hg::ssh://hg.mozilla.org/releases/mozilla-aurora
  (...)

• For each of those remotes, set a refspec that limits to pulling the tip of the default branch:
  

  $ git config remote.central.fetch +refs/heads/branches/default/tip:refs/remotes/central/default
  $ git config remote.inbound.fetch +refs/heads/branches/default/tip:refs/remotes/inbound/default
  $ git config remote.aurora.fetch +refs/heads/branches/default/tip:refs/remotes/aurora/default
  (...)

  Other branches can be added, but that must be done with care, because not all branches are exposed on gecko-dev.

• Set git-cinnabar grafting mode permanently:
  

  $ git config cinnabar.graft only

• Make git-cinnabar never store metadata when pushing:
  

  $ git config cinnabar.data never

• Make git-cinnabar only graft with gecko-dev commits:
  

  $ git config cinnabar.graft-refs refs/remotes/origin/*

  (replace origin with the remote name for gecko-dev if it's not origin)

• Then pull from all remotes:
  

  $ git remote update

  Retry as long as you see errors about "Not allowing non-graft import". This will keep happening until all Mercurial changesets you're trying to pull make it to gecko-dev.

With this setup, you can now happily push to Mercurial and see your commits appear in gecko-dev after a while. As long as you don't copy or move files, their SHA-1 should be the same as what you pushed.

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.

Get it on github.

What's new since 0.2.1?

• Don't require core.ignorecase to be set to false on the repository when using a case-insensitive file system. If you did set core.ignorecase to false because git-cinnabar told you to, you can now set it back to true.
• Raise an exception when git update-ref or git fast-import return an error. Silently ignoring those errors could lead to bad repositories after an upgrade from pre-0.1.0 versions on OS X, where the default maximum number of open files is low (256), and where git update-ref uses a lot of lock files for large transactions.
• Updated git to 2.4.0, when building with the native helper.
• When doing git cinnabar reclone, skip remotes with remote.$remote.skipDefaultUpdate set to true.