ingoem / scala-swing Goto Github PK

The current EditableCellsCompanion design doesn't offer the same degree of abstraction and reuse as the renderers.

One big problem is DefaultTreeCellEditor, which contains indispensable functionality, but requires an actual JTree instance to be created, and thus can't be handled at the companion level.

I encountered an issue with exceptions and scala-swing here:
http://groups.google.com/group/liftweb/browse_thread/thread/a30235375b426bd3/f7e89f917dcf6135?lnk=gst&q=tommycli#f7e89f917dcf6135

Summary: RuntimeExceptions produce stack trace correctly, while regular Exceptions never show the stack trace.

Thought someone here might be able to shed some light.

My common Renderer[-A] trait has the following method signature:

def componentFor(owner: Owner, value: A, cellInfo: companion.CellInfo)

Where Owner is say, a ListView[], Tree[] or Table, and CellInfo contains the extra component-specific stuff like row, isSelected, isFocused and so on. (Assuming ListView and Table are retrofitted with CellView/RenderableCellsCompanion and so forth)

The advantages of this abstraction are compelling; for instance, this mixin will provide an identical renderer for Tree, ListView and Table:

trait RenderFiles {
  this: RenderableCells[File] =>
  import companion._
  renderer = Renderer(_.getName)
}

Also, the LabelRenderer implementation in Table can be entirely pushed up to the CellRendererCompanion level of abstraction.

However this causes backwards compatibility issues with the existing componentFor methods in Table and ListView. I have made some attempt at accomodating user code that overrides either, but it may still break existing code. I'm not sure how to handle this case.

So far I've used scala.List as the type of Tree.Path, but it has some problems:

• The most useful element, the last one, can only be accessed in O(n) time; it should really be some kind of IndexedSeq.
• Using a List type alias locks us into the List API, and denies us any future flexibility in adjusting the functionality behind this API.

On the other hand:

• What I liked about List was the root :: branch :: leaf syntax for initialisation and pattern-matching, which is a nice way to represent a tree path.

Perhaps a new class Tree.Path is appropriate?

By default, the TreeModel uses a virtual tree structure; the user's data is queried as needed and the structure is not copied into an explicit tree structure, such as DefaultTreeModel/DefaultMutableTreeNode. This works very well for most things, and is very simple to set up.

However it won't always do; for instance the file-system example in the TreeDemo is directly querying the file-system to form the tree, and any unexpected changes in the files system won't give the necessary notification. Here, and in other cases, it would be beneficial to copy the whole structure into a generic Node representation.

I think it would be beneficial to have "official" node structure, in addition to the straightforward virtual model, similar (or perhaps identical!) to DefaultTreeModel/DefaultMutableTreeNode. A method to instantly transfer a tree model into a standalone model could be useful, such as:

new Tree[File] { 
  treeData = TreeModel(new File(".")) {f =>
    if (f.isDirectory) f.listFiles.toSeq else Seq()
  }.copyNodes()
}

Is there a better way of doing this? I'm wary of adding too much independent functionality into what is supposed to be wrapper framework, but it still seems somewhat beneficial.