In the old Redcar, the directory tree was tightly bound up with Gtk, handling drawing all its own rows and responding to Gtk events. It worked, but there was only one thing it was good for: viewing directories.

In the new Redcar the concept of a tree has been cleanly separated from the concept of a directory viewer. The project directory view is just another implementation of the same TreeMirror interface that you can implement in your plugins. There is nothing special about it.

In the previous post Redcar REPL I discussed the DocumentMirror, which is a simple interface you can implement to let Redcar users edit any resource you like.

The tree is similar. The concept of a tree is entirely represented by two classes. The first is the tree itself, which must have a name and provide a method to get the top elements. The second is the row in the tree, which must provide its text, its icon and its children. And that’s about it.

So implementing your own looks something like this:

class MyTree
  include Redcar::Tree::Mirror

  def name
    "My Tree"
  end

  def top
    [ ... MyNodes ... ]
  end

  class MyNode
    include Redcar::Tree::Mirror::NodeMirror

    def text
      "Some tree entry"
    end

    def icon
      :file
    end

    def leaf?
      false
    end

    def children
      [ ... MyNodes ... ]
    end
  end
end

It’s a recursive definition, with every node’s children being more nodes. Redcar traverses this tree structure and handles all the gui for you. You just have to implement these two classes according to whatever domain you are working in, and then Redcar has enough information to display a tree for you. You can look at the implementation of the directory viewer on Github for an example.

This interface should make it trivial to implement new trees in Redcar. Some ideas:

• Class browser
• Test runner
• Rake task browser

It may be an interesting challenge to write any one of these, but at least the “tree” part will be trivial thanks to the new TreeMirror interface.