SIL LSDev Linux Development

Language software for Linux and Mac OS X

FieldWorks Beta 2 released

Earlier today we issued our first beta release of FieldWorks for Linux. Although this is the first beta for Linux, it’s actually numbered Beta 2 because it’s equivalent to the Beta 2 that has just been released for Windows. We did try to produce a Linux equivalent of the Windows Beta 1 but we encountered some crashing bugs when we integrated the latest changes from the Windows branch of the source code, and by the time we had fixed those, Beta 2 was almost ready. This is the first time that the Linux and Windows versions have come out together, and with the same version numbers. If we find it necessary to issue updates before Windows Beta 3, we will number them Beta 2.1 and so on. Hopefully this will make it much easier for users to know how the different releases match up on the different platforms.

The releases for the two platforms are built from the same source code—almost! The Windows and Linux development teams actually do their work on separate branches, just so they don’t get in each other’s way when a release is imminent, but we usually copy the changes back and forth between the branches a couple of times per week.

We believe this release is much more stable than anything we’ve released previously, and it also has more functionality. For example, it’s now possible to use the full range of data import and exchange possibilities, including opening project files copied from Windows, and opening FW6 backup files.

As always, instructions are on the wiki. Please continue to report bugs, and write comments here to let us know how things are working for you. There is a lot of interest in Linux in SIL right now, but questions are also being raised about whether the cost of doing Linux development continues to be justified. So please let your colleagues and associates know that you are using Linux, and explain how it’s meeting real needs in language development.

Linux-first development!

One of our long-standing goals has been that FieldWorks development could eventually be carried out on either platform, and target both platforms. Last month, the very first example of this started to happen.

Read the rest of this post…

Source code unification

We reached a significant milestone recently when we re-integrated all of the work we’ve done over the past several years to port FieldWorks to Linux. There’s now a single source tree, in a single version control system, that contains both the Windows and the Linux versions of FieldWorks.

Read the rest of this post…

Why Firebird? Why not a Different RDBMS?

David asked, “I’m curious to know why Firebird has been chosen as a database engine [for FieldWorks] out of the many other RDBMSs out there, such as MySQL.”

I get this question from time to time, especially when I go to our Computer Technical Conference (CTC), which comes around every two years.  It is a fair question, and since CTC is just a month away, I’m taking the opportunity to remember why we did what we did. I had to ask the people that made the decision, because I had a hard time remembering. It’s been a few years.

Read the rest of this post…

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.

COM in Linux

The core of SIL FieldWorks was written in C++. New development in FieldWorks is done in C#, and ties into the C++ core through COM.

After much looking all over the Internet in January 2005, I basically concluded that not only does no one use COM in Linux, but no one wanted to (outside of big enterprise application ports to UNIX).

When both porting FieldWorks to Linux and making it cross-platform, we lose access to Microsoft’s COM implementation in Windows. We were originally going to use SWIG to generate C# wrappers around the C++ core libraries. All C++ methods would then be P/Invoked, and COM would be bypassed.

Then I found that Jonathan Chambers had put a lot of good work into Mono‘s COM support. I was able to have a C# COM client access a C++ COM server in Windows using Mono.

Read the rest of this post…

The look and feel of cross-platform user interfaces

Someone just asked me,

What’s the best way to do a cross-platform product that has the native XXX look and feel?

It depends on exactly what you mean by native look and feel. There are several GUI toolkits that produce the right pixels, so that in a screen shot it would look just like an XXX application, but which still don’t produce an application that feels right. For example, on Mac, if you select a range of text and then press right-arrow, what happens? The insertion point should move to the right boundary of the previous selection. However, on Windows, it typically moves one character beyond that point. I find this inconsistency very frustrating in several of the cross-platform apps that I use regularly.

Also, applications may have the right pixels for all the individual controls, but the overall layout of their UI doesn’t feel comfortable for an XXX user. The classic example is the relative ordering of OK and Cancel buttons in dialogs. Most toolkits now take care of this transparently, but there are other things, such as the extent to which toolbars are used, that can be uncomfortable for users. For example, Mac applications typically use toolbars very sparingly, and Windows apps use them extensively.

Read the rest of this post…

Mono 1.2

Today I read the Mono 1.2 release notes. A few things stuck out to me:

  • full implementation of 1.0 and 2.0 APIs
  • full SWF 1.1 API
  • MONO_IOMAP setting may help with some potential crossplatform issues
  • Bundles. If our COM implementation ends up being rather Frankenstein (or really cutting-edge :) ), Bundles would let us distribute our own custom Mono along with the application. I don’t really see this as a desirable solution, but it’s nice to know it’s there.
  • “Support for the registry is now provided on Linux and Windows.”