SIL LSDev Linux Development

Language software for Linux and Mac OS X

Translation Editor running on Linux!

TE Draft View of Jonah in Sena

Today was a milestone. We demonstrated the Linux version of FieldWorks TE to a group of people at the office chapel time. It worked well enough for the demo, in that it wasn’t slow and didn’t crash, and the people were impressed :-)

Progress has been very rapid in the past month or two, for several reasons, but today was the first time that we felt TE was ready to show to others. It was helpful to have the extra incentive of a scheduled demo for the final push to get things working on a non-developer machine.

Read the rest of this post…

Status of WorldPad on Linux

Our team’s main focus has been to port the SIL FieldWorks suite of translation and linguistic programs from Windows to Linux.

We’ve ported the core C++ parts which are the foundation of all the FieldWorks applications. A big part of the remaining work is in C# to get Translation Editor and Language Explorer to build and run in Linux.

But tackling Translation Editor would be quite a big step and open up a lot of difficulties all at once. So first we’re working to port WorldPad. Although WorldPad won’t be as widely used as Translation Editor, our work on WorldPad is a stepping stone on the way to completing the Translation Editor because many pieces of WorldPad are shared by Translation Editor. And completing the Translation Editor will be easier if we first work on WorldPad.

Because WorldPad is older than Translation Editor, we’ve first changed some of the underlying technology to put us in a better position to transfer our work to Translation Editor. WorldPad in Windows is a C++ application wrapping views, a library in the FieldWorks code that allows fast display and editing of writing systems with complex scripts and other unique features required by minority language writing systems.

We’re writing another WorldPad, WorldPadGTK, using C# and embedded the view in a GTK window. WorldPad in Linux will be a C# GTK application wrapping views.
WorldPadGTK Screenshot 20080829

Updated code repository to latest from Dallas

As much of our porting work has been dealing with Windowsisms in the lower levels of the FieldWorks code, which wasn’t expected to change a lot in the Dallas VCS, the code in our local VCS had grown quite out of date. Two and a half years out of date!

Since we’re now using areas of the code that have had a lot of changes during that time, there was an increasing need to update our local VCS to reflect the latest from Dallas.

First I migrated our VCS from CVS to SVN - a welcome change. (I can rename directories now!)

Then we merged in the new code from Dallas, resolved the conflicting files (only 93), and made things still compile in Linux.

After having approached this with apprehension, I was thankful that it was easier than I had anticipated and only took two and a half weeks.

And now we’re up to date!

.NET LINQ to Firebird

Since we’re porting from SQL Server to Firebird, code that works on both RDBMSs is highly valuable. We want to connect to either using C#.

Microsoft’s ADO.NET Entity Framework does just that. One of the components is LINQ. Here is a beginner’s application to show how to do it with Firebird.

Download and run the latest Firebird Data Provider for .NET and Mono.

Open Visual Studio 2008 (VS). You can try using 2005, but I couldn’t get it to work. Create a new project. (File/New/Project…) Under “Project types” select Windows. Under Templates select Console Application. Give it a name. (I used LinqToFirebird.) Give the project a location. I prefer to leave the checkbox “Create directory for solution” unchecked, to avoid a deeper directory tree than I want.

In VS, go to the Solution Explorer. We’re going to add a reference to the Firebird .NET Data Provider. Right-click on References. A dialog will appear. Select the Browse tab. Go to the directory where you installed the provider and select FirebirdSqlData.FirebirdClient.dll

Now we get to code. In Program.cs, add the following above namespace at the top:

using System.Data;
using FirebirdSql.Data.FirebirdClient;

In the Main method, use the following code. You will have to change the connection string to your own, of course. (The best site for database connection strings is ConnectionStrings.com.) Microsoft has a number of examples for LINQ.

FbConnection con = new FbConnection(
“ServerType=0;User=SYSDBA;Password=masterkey;Dialect=3;” +
“Database=C:\\Firebird\\Data\\FieldWorks\\FW01.FDB;”);

FbDataAdapter fbadapt = new FbDataAdapter(
“SELECT * FROM RDB$CHARACTER_SETS;”, con);

// Table mappings
fbadapt.TableMappings.Add(”Table0″, “CharSets”);
DataSet dataset = new DataSet();

// Fill the dataset with a call to the database
fbadapt.Fill(dataset);

// Query
DataTable CharSets = dataset.Tables[0];
var queryCharSets =
from rCharSets in CharSets.AsEnumerable()
select rCharSets;

Console.WriteLine(”RDB$CHARACTER_SETS:”);
foreach (DataRow rCharSets in queryCharSets)
{
Console.WriteLine(rCharSets.Field(”RDB$CHARACTER_SET_NAME”));
}

// pause
Console.ReadLine();

CloseConnection(con);

A significant milestone

As a result of the breakthrough described in the last post, Brent was able to get a sample application running (HelloView.Net). It’s written in C#, runs on Mono, and uses the FieldWorks infrastructure packaged as COM objects. In particular, it uses the Views component of FieldWorks, one of the key pieces of the infrastructure, and this is the first time that Views has ever run on a non-Windows platform.

Read the rest of this post…

A long-awaited breakthrough

Our porting work depends on having a link from C# to C++ using COM. This is a fundamental requirement, and without it we cannot proceed. Although we’ve had this working in small test programs for a long time, it would crash badly when we tried it with our application (WorldPad, part of FieldWorks). We were fairly sure it was something we were doing wrong, but could never pin it down. Well, now Tom and Brent have found the solution!

Read the rest of this post…

libcom 0.4.0 released

The libcom COM Support Library version 0.4.0 has been released. This is the first release of libcom. libcom is licensed under the LGPL.

libcom implements a subset of Microsoft COM (Component Object Model) and supports both C++ and C# (via Mono) COM clients and servers on Linux. libcom is similar to ole32.dll in Windows.

libcom can be downloaded from http://linux.lsdev.sil.org/wiki/index.php/Downloads.

Update: libcom now has its own web page at http://linux.lsdev.sil.org/wiki/index.php/Libcom.

C++ accessing C# COM objects through CCW in Mono on Linux

Recently we had a couple developers from other offices join us for LSDev Linux Brainstorming Week to learn from one another, talk about technology choices, and do some pair programming.

Recognizing that parts of our C++ code need to be able to access and work with C# objects through COM (Component Object Model), Eberhard and I set out to test this in Mono on Linux.

We were successful in making a C# application create a regular C# object and a C++ object (via libcom and RCW), pass the C# object to the C++ object, have the C++ object modify the C# object from native code, and then back in C# code observe that our C# object was indeed manipulated successfully from C++.

This capability to call back and forth between C# and C++ using COM is very important for porting several SIL programs to Linux, and we were concerned about whether it would even be possible with Mono. We found out several months ago that C# calling into C++ using libcom and Mono RCWs worked, and I was pleased to find that going the other direction, C++ calling C#, elegantly Just Works.

This new test works thanks to Jonathan Chambers’s implementation of COM Callable Wrappers (CCWs) in Mono, which was announced here.

Eberhard and I largely reused existing libcom test code and just made some additions. The steps to perform this test and an explanation of what is happening can be found on our wiki here.

Graphite and OLPC

It may not have been obvious from the last two posts, but we are taking steps towards getting Graphite working on the OLPC. Read the rest of this post…

Our own OLPC

We’ve just received our own OLPC hardware, through the beta programme. It is an XO B2. The hardware is really nifty, although surprisingly heavy. The software is still a little rough in places, but continues to improve at an amazing rate.

We’ll be experimenting with it in all kinds of ways, but the real reason for having it is so that we can try porting various pieces of our software to it and see how well they work on it. In particular, we’d like to see how Graphite performs there.

« Previous Entries