This week we tried to get Greenstone 3 to work on on Dr John Brine’s 64-bit Mac OS 10.6.6 machine (with Update 3) so that the Flax developers could make sure that Flax, which works with Greenstone 3, would run as well.

We didn’t have admin access on Professor Witten’s machine of similar specs, and therefore could not install the Java Developer Package which would contain the jni.h and other header files that had been relocated since Mac 10.6 Update 3 and whose absence prevented proper compilation on such Macs. However, on Dr John Brine’s machine, having admin privileges meant we could install this and get Greenstone 3 to compile on a Snow Leopard Update 3 at last. Running was  a separate issue: there were problems with the server. Sam discovered that the Java Developer Package (which contained JDK 1.6.0) would be 64 bit as well and found a flag to force Java to run in a 32 bit mode: -d32. Upon using that flag to launch the Apache web server, things ran smoothly on the server side of things. There are still issues with GLI opening collections and re-building collections in Greenstone which we will be returning to later.

Some configure and makefiles were updated to allow Greenstone to compile without compiling up wvware (since this had libiconv problems on the Mac 10.6.6, and compiling up gnome-lib on the machine has issues of its own). The –disable-wvware will allow us to temporarily bypass that and focus on other problems first.

In between, another staff member had moved his 3-year old Greenstone 3 installation elsewhere and his Greenstone web-service related application had stopped working. We got a new version of Greenstone 3 and made some configuration changes to get it all to work again.

Then it was back to testing Greenstone 2.84 to ensure that the important fixes Sam and Dr Bainbridge had made in the last weeks interacted well. I’m onto Mac testing at the moment. By Friday, we discovered that while documents with non-English unicode filenames were mostly working on the Mac, HTML files that interlinked (where the links referred to non-English filenames either directly or in URL-encoded format) did not. We started investigating this.

Hello Greenstone users, welcome to week 4 of my weekly blog about Greenstone development. This week I have spent most of my time working with the developers of FLAX to create an installer that will work on the most recent versions of the MacOS operating system. Those of you that use FLAX may know that it is built upon Greenstone 3 and, up until this week, the developers of the FLAX have used a modified version of the system that is used to create our Greenstone binary installers (which we internally call the release kits). I have been working with them to merge their modifications into the main release kit code so that they no longer need to keep a modified version and can simply have the release-kits enable FLAX compilation with a single switch. As part of this, several extra features were added to the Greenstone 3 compilation script, such as the ability to disable GLI and GEMS, and disabling JNI now correctly excludes the files that use it from the compilation process.

We now know enough about the Mac issues I discussed in my previous blog entry to create a version of FLAX that will (hopefully) work correctly on both the older versions and the new versions of the MacOS operating system. This is still an unsolved issue for Greenstone 3, but this is a low priority for us at the moment as the majority of our focus is on releasing Greenstone 2.84, which is currently in its final stage of testing.

See you all next week!

I don’t really have a lot to report from last week as I was away sick for some of it. We have been investigating problems with Greenstone 3 on the most recent versions of Mac OS. As some of you may know, Greenstone 3 is programmed heavily in Java which is ideal for cross platform development. Unfortunately for us, Apple recently decided to deprecate Java on their operating system and – to cut a long story short – it makes things much more messy for us. There is also an issue on some Macs (presumably ones with later versions of the compiler we use), where they attempt to compile Greenstone as if it is 64-bit. Although we are currently working on a pure 64-bit version of Greenstone it is currently not at the stage where it is ready to be included into the main part of the code. Unfortunately we only have limited access to computers with the latest Mac OS, so finding a solution to this problem may have to wait till we can get more permanent access to a machine like this.

Anyway, see you next week!

Welcome to week two of my new weekly blog about developing Greenstone.

This week has been quite successful as I have managed to achieve all of the things I set out to do in the previous blog and more. The ‘Oran’ skin is nearing completion now, we just need to get some real users in so we can evaluate both its functionality and its appearance.

As well as there being the small Javascript error in the Berry Basket code that I mentioned last time, there was also a bigger issue that was preventing us from displaying the quick search box on one of the Berry Basket pages. As some of you may know, Greenstone 3 uses technologies such as XML and XSLT to generate the web pages of the Greenstone Reader’s Interface. Greenstone 3 itself is made up of various Actions (that produce the XML for various types of pages) and Services (used by the Actions to do the hard work like retrieving document content or perform a query on a collection), one of which being the Berry Basket service. The quick search box requires information about TextQuery service in the collection that the user is currently within in order to generate a search box that will search that specific collection. The way one of the Berry Basket pages is created however does not make it easy for this collection information to be accessed. It uses a General action who’s ‘c’ parameter stands for Cluster instead of the more-standard Collection, so simply giving the action the current collection in the ‘c’ parameter was not sufficient as it would be for most other pages. We eventually decided that the tidiest fix was to save the collection in the ‘p.c’ parameter and to modify the Receptionist (the part of the code that produces the necessary extra information about that collection) to first look for the current collection in the ‘c’ parameter and if that did not exist then use the ‘p.c’ parameter.

If you’re still here then well done! My average day as a programmer consists of solving lots of these little problems. It may not sound very interesting to the average person but there is definitely a good sense of satisfaction when you find a way to solve these complex problems.

This week I also added a handy little feature that will prompt a user if they make a change in the preferences page and try to leave the page without hitting the “Set preferences” button. It asks them if they want to save their preferences, and if do it will go ahead and save it for them and take them to their new page. Doing this in a way that worked happily on all of the major browsers (Internet Explorer, Mozilla Firefox, Google Chrome and Apple Safari) was actually quite tricky. One way that I implemented worked happily on IE and Firefox but refused to work on Chrome/Safari. This ended up requiring a whole different approach, (involving a synchronous AJAX call in the “beforeunload” Javascript event for those who have some Javascript experience).

Anyway, that’s enough for this week. See you next week!

Ok, so one of the things us Greenstone developers are going to try to do from now on is blog each week about what we’ve achieved that week. Ideally we’ll try to do it on Fridays, before we leave for the weekend (so this entry is a few days late).

This week I have been working hard on the development of the new default skin for Greenstone 3 – codenamed the ‘Oran’ skin. For those of you who don’t know, Oran worked here before me and I effectively took his place when he moved on to a new job. One of the things that he had been working on was this new and fresh-looking skin for Greenstone 3, and this week I have been working hard to get it ready for the Greenstone 3.05 release which will happen later in the year.

One new feature that is worth mentioning is the addition of a quick search area that is permanently in the header of the page (assuming the collection has basic query capabilities). So regardless if you’re browsing or reading a document, a basic search field is always available.

I have also been working on fixing the Berry Basket feature that was added into Greenstone 3 a while ago but had stopped working due to other changes that had been made. Having fixed the main problem (a small javascript issue) I then discovered that it did not work correctly in Internet Explorer. So this week I will be focusing on that and other Greenstone 3 user interface related issues.