lcdui is the ‘GUI’ that is provided with j2me for environments like cell phones. The second version of the API, MIDP2.0, has been cleaned up some with respect to MIDP1.0, but since I want to target as wide a range of devices as possible, I need to make Hecl work as well as possible within the limitations of MIDP1.0.

The latest problem I have encountered is the differences between the List and ChoiceGroup widgets. These are supposed to provide radio buttons or checkboxes, depending on which attributes you specify, with List being the “full screen” version, and ChoiceGroup being an Item that can be included as one component of a form. Form items can register for callbacks via itemStateListener, which is called when the form item’s state changes. Lists do not have this capability though, so you have no way to register callbacks when a List item is selected or deselected.

To remedy this, I decided that I’d just make my own ‘full screen list’ by creating a form with one ChoiceGroup, which works something like this:

public class ListBox extends Form {
    public ChoiceGroup cg = null;

    public ListBox(String title, int choicetype, String []choices) {
        super(title);
        cg = new ChoiceGroup("", choicetype, choices, null);
        this.append(cg);
    }

    public int append(String item) {
        return cg.append(item, null);
    }
}

some details ommitted, but that’s the idea. So far, it seems to be working exactly as I needed – I was able to define a callback that performs an action when all checkboxes were checked.

The only thing I can think of that I’d need an actual List for is to define some sort of menu that performs some action when an entry is selected, via the IMPLICIT Choice type.

Apparently, this problem with List’s has been fixed in MIDP2.0, but… there are a lot of phones on sale that still ship 1.0, so it’s going to be with us for a while yet.

Rivet has been seeing some increased visibility these days, but it seems that people are encountering a great deal of difficulty installing it due to problems with autotools.

This is extremely frustrating to me, because the code itself works fine. It’s all the installation crap that always seems to have problems, on all major platforms. I built and tested the latest version on Ubuntu, and everything was working fine. But there have been problem reports for Fedora, MacOS X (although that’s not an autotools error – Karl Lehenbauer wasn’t even able to make autotools work for MacOSX, so we switched back to the Tcl based build system) and Windows.

I really want this stuff to work, and people aren’t going to use it if they can’t build and install it. On the other hand, people need to help out on the platforms they are knowledgeable with because I’m limited in what I can do on certain platforms.

On the whole, it’s all quite frustrating and leaves me even more unhappy with autotools than I was before. The Rivet code is good, and we’re happy with it, but we find ourselves with something that feels like a …barrier…between us and our users.

Update

Problems are getting cleared up, but it’s still frustrating. As everyone who’s worked with auto* knows, debugging these things is sometimes a black art.