Skip to main content

Tree editing, bidi compliance and other woes...

No replies
Anonymous

Hi Folks,

for the last couple of days I dived into the intricacies of tree editing
(now I know why I never wanted to do so before :-). The triggering issue
was that TreeTableCellEditor wasn't bidi-compliant, then it turned out
that editing JXTree wasn't as well - and neither is editing JTree.
Taking the short-cut to ask Scott (sorry for pushing you, but who knows
how long I still can do without overstressing your patience) got me a
pointer to the appropriate bug and it's state:

>> Definitely a bug. It's filed as 4980473.

>
> It won't be until 1.7:( This bug was owned by the i18n team, and it
> recently got reassigned to me because they're overloaded, hence the
> delay. That said, if Shai fixed it via http://jdk.dev.java.net there is
> a good change it would make it into 1.6.
>

Being too impatient to wait or go the long way (after all, I would be
satisfied to have SwingX work correctly, core Swing is free to take it
) I plunged into. Here's a summary:

SwingX has a first hack around in the tree package:
DefaultXTreeCellEditor extends DefaultTreeCellEditor and simply adds
isRightToLeft branches to every method of EditorContainer which need to
be aware of CO. So LToR orientation context are uneffected, RToL is
trying its best to mirror the coordinates (probably missed the one or
other pixel, but overall the RToL experience is considerably improved,
IMO, but then I might be wrong ;)

While playing with it I felt a strong urge to "tweak" (might turn out as
a dead end, but even then I will have learned a lot about dirty details
of tree editing, the state transitions are quite involved :)

- the editor isn't bidi-compliant, for my feeling I had to touch far too
many methods to make it halfway behaved. The main reason it was so hard
is the manual layout
- the editor can't cope with renderers different from
DefaultTreeCellRenderer
- the editor can't cope with "dynamic" icons (read: if the renderer
decides to set value-dependent icons), always uses the default icons as
given by the defaultTreeCellRenderer
- the editor is not shareable across tree instances

My first go on a solution is in the my incubator space (src/kleopatra),
DefaultXXTreeCellEditor in the swingx.tree package - plus a demo
TreeEditing (which requires swingx and swingx test classes, sorry about
the inconvenience).

The basic changes are

1) make EditorContainer behave as a real container with a label to paint
the icon. This alleviates much of the pain of achieving bidi-compliance

2) always get the tree renderer from the tree and configure it
appropriately (either from the parameters as given in
renderer.getxxComponent or from the parameters as retrieved from the
current tree state at the treepath under the mouseEvent). Then check the
returned rendererComponent for the icon (works only for JLabel, but then
most are, subclasses can override to use reflexion if needed). This
covers all the other issues above (in principal, at least )

The state handling (listening, keeping track of last selected, last row)
is essentially unchanged, only refactored so that I could understand
what's going on.

I would love to get feedback from the tree experts - my exposure to it
always was very detached (closed my eyes and hoped for everything to
work out-of-the-box, which mostly worked).

Now I'm hungry (for food), cheers and have a nice evening/day whereever
you are!
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net