Bloom is open source, using the MIT License.
See the Bloom Trello Board.
Reports can be entered in http://jira.palaso.org/issues/browse/BL. They can be entered there via email by sending to issues@bloom.palaso.org; things sent there will be visible on the web to anyone who makes an account on the jira system.
Each time code is checked in, an automatic build begins on our TeamCity build server, running all the unit tests. Similarly, when there is a new version of some Bloom dependency (e.g. Palaso, PdfDroplet, our fork of GeckoFX), that server automatically rebuilds Bloom. This automatic build doesn't publish a new installer, however. That kind of build is launched manually, by pressing a button on the TeamCity page. This "publish" process builds Bloom, makes and installer, rsyncs it to the distribution server, and writes out a little bit of html which the Bloom download page then displays to the user.
Bloom is written in C# with Winforms, with an embedded Gecko (Firefox) browser and a bunch of jquery-using javascript. You will need Visual Studio 2010 SP1, or greater, to build it. The free Visual Studio Express version should be fine, but we don't test it.
To get the source code, you'll need Mercurial. Windows users, install TortoiseHg. Then from a command line, go to where you keep your development projects, and give this command:
hg clone http://hg.palaso.org/bloom
You should now have a solution which you can build using any 2010 edition of Visual Studio 2010, including the free Express version. We could help you do it in VS 2008, if necessary.
Now, what revision should you be on? If you're not familiar with DVCS (Distributed version control), this could be a big stumbling block. I hesitate to give advice in this document in case I forget to update it. But a reasonable start is to update to the tip revision, which is the most recent one that anyone has checked in, regardless of which branch it is on. To update to the tip, do:
hg update tip
It will avoid some complications if you do that now, before adding the dependencies which follow.
Some of the dependencies are very large, and others are updated frequently. For both of those reasons, you can't just pull the code and expect it to compile. First, you will have to do some extra work to get Bloom's library dependencies complete and up to date. To make that easy, each time our TeamCity server builds Bloom via Bloom-Default-Win32-Auto, it creates a Bloom32Dependencies.zip file, which has one file for distfiles (exiftool.exe), and a bunch of files for the lib directory, including the full xulrunner. Extract this file on top of your bloom source directory, allowing your zip utility to replace any conflicting files with the ones in the zip file:
If you'll be working with Send/Receive, please copy the "Mercurial" and "Mercurial Extensions" folders from an installation of Bloom to the root of your Bloom source directory.
Next, find and double-click "Bloom VS2010.sln" and choose "Debug:Start Debugging". Problems? Don't get frustrated, just drop us an email: hattonjohn on gmail.
Our Palaso libraries hold the classes that are common to multiple products. If you need to build palaso from source, see projects.palaso.org/projects/palaso/wiki.
Our **PdfDroplet **engine drives the booklet-making in the Publish tab. If you need to build PdfDroplet from source, see projects.palaso.org/projects/pdfdroplet/wiki.
Our Chorus library provides the Send/Receive functionality.
GeckoFX: Much of Bloom happens in its embedded Firefox browser. This has two parts: the XulRunner engine, and the GeckoFX .net wrapper.
GeckoFX is included in the BloomWin32Dependencies.zip file. If you need to build GeckoFX from source, see https://bitbucket.org/geckofx. Note that Bloom is actually built off of the Hatton fork. In either case, you'll need to figure out which version of gecko (firefox) Bloom is currently using.
XulRunner: If you need some other version that what is already in the BloomWin32Dependencies.zip, they come from here: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases. You want a "runtime", not an "sdk". Note, in addition to the generic "lib/xulrunner", the code will also work if it finds "lib/xulrunner8" (or 9, or 10, or whatever the current version is). I prefer to append that number so that I'm clear what the version of xulrunner is that I have sitting there.
More information on XulRunner and GeckoFX: Firefox is a browser which uses XulRunner which uses Gecko rendering engine. GeckoFX is the name of the .net dll which lets you use XulRunner in your WinForms applications, with .net or mono. This is a bit confusing, because GeckoFX is the wrapper but you won't find something called "gecko" coming out of Mozilla and shipping with Bloom. Instead, "XulRunner" comes from Mozilla and ships with Bloom, which accesses it using the GeckoFX dll. Got it?
Now, Mozilla puts out a new version of XulRunner every 6 weeks at the time of this writing, and Hindle's GeckoFX keeps up with that, which is great, but also adds a level of complexity when you're trying to get Bloom going. Bloom needs to have 3 things in sync:
- XulRunner
- GeckoFX intended for that version of XulRunner
- Bloom source code which is expecting that same version of GeckoFX.