[nebula-dev] [compositetable] different suggestions

["David J. Orme" <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi Andr

> I plan to use compositeTable as a replacement to classic tableViewer in
> my current Eclipse RCP client. I have to display 100'000+ rows and I was
> very pleased by its design.

Thanks!

> - dialog cells:
> I have cells that display references. When a user wants to edit them I
> have to present a dialog that shows possible values and the possiblity
> to delete the current reference (ok, cancel, delete). I started looking
> trough your key handling in InternalCompositeTable and I'll probably use
> space & double Click to activate the dialog.

Key handling/binding as it stands is a problem.  All key bindings are currently hard coded, and things like Ctrl-insert to insert a new row are not cross-platform compatible since Mac laptops don't have an insert key.

The problem is twofold:

1) Key bindings need to be flexible.

2) The API should make easy thins simple and hard things possible.  Which is to say that default key bindings should be configured with a minimum of fuss.

I'm leaning toward some kind of strategy pattern object for defining key bindings.  CompositeTable itself would expose API for each command:

public void executeInsert();
public void executeDelete();
...

addKeyListener() on CompositeTable would return *all* keystrokes of *all* controls inside CompositeTable.

The strategy pattern object would add a key listener, and delegate the key events to handleInsertKeystroke, handleDelete keystroke, etc:

public class KeyBindingStrategy implements KeyListener {
  public void keyPressed(KeyEvent e) {
    if (handleInsertKeystroke(table, e)) return;
    if (handleDeleteKeystroke(table, e)) return;
      ....
  }

  public boolean handleInsertKeystroke(CompositeTable t, KeyEvent e) {
    // If key event is the key bound to the insert command, call t.executeInsert()
  }
  //...
}

Then clients could selectively override default key bindings by overriding just individual handle...Keystroke() methods.

> - navigation & cell activation
> One important requirement is key based navigation. I tried to use native
> combos in cells and everything works fine on my gtk+ box. You can press
> alt+arrow down to show the list of selectable values. CCombo on the
> other hand looses the focus when navigating in the list. I assume that
> this is due to the difference where combo keys are handled natively.
> CCombo fails to superseed its binding to the internalCompositeTable
> bindings. If you try to navigate the items with the arrow key, the list
> gets closed and the table passes the focus to the next (lower) cell. I
> admit, that it would be nice to have a common behaviour to all cells,
> ex. space activates additional editing-widgets. But this would lead to a
> celleditor-like API. I suppose that's not what you wanted to end in?

Right; if you need a cell editor API, you would build that into your row objects that CompositeTable uses.

In our project, we have run into this problem and others with using CCombos.  We have replaced them with regular Combos everywhere.

> - columns?
> Another feature I think of is the capability to show/hide columns. The
> current code uses a pure row based design. It would probably be nice to
> refactor it to know the concept of columns, too. The framework could
> supply default column implementations for common data types. ex. an
> Integer-column would supply a text widget whereas Boolean-columns would
> supply a checkbox. Another benefit would be the possibility to supply
> default comparator support with it. A user implementator could have a
> working table with a minimum of code.

This makes sense too, but I believe it belongs in the row object layer on top of CompositeTable.  There is new work to provide a default Header object that uses the native Table to get a native header.  This will work with a custom layout manager to enable column resizing and moving.  Take a look at the snippets in CVS to get a taste for how this work-in-progress code will function.  I'd *love* to have your feedback on the design and implementation.

Thanks very much for your feedback!!!  I really appreciate that.

Best regards,

Dave Orme