Sneak Preview: new SwingX JXTreeTable - queen-quality

[Kleopatra]

.. whatever that's worth <g>

As already announced in the other thread:



I had been playing with Netbean's new Outline related parts. It's been
veery goood start - but still required lots of work (<evil grin> Tim,
you did get the event notification only slightly more correct as we had
it - probably didn't look into the SwingX sources/issues?</evil grin> My
incubator version comes with a text file where I jotted down the
thingies I found during my experiments).


The code is in the swinglabs incubator, src folder
src/kleopatra/foreign, package netbeans.xoutline. Compiles with 1.6 (or
1.5 with target 6. target 5 doesn't work due to the changed @override
tag only - myyy dear, is that annoying!) The participants


*XOutlineModel*

that's the (mostly internal) model for the treetable. It is-a TreeModel
and is-a TableModel, has additional functionality to convert
row-coordinates to path-coordinates (and vice versa) and to control the
expansion behaviour.  In contrast to the original, it exposes that
functionality in its api. Currently, it still exposes the internal
controllers (LayoutCache for the row-mapping services and
TreePathSupport for the expansion) but I hope to get that hidden soon.


*TreePathSupport* (probably to be renamed to ExpansionControl or similar)

this is the break-out of the expansion control in JTree: encapsulates
expansion memory and will/expand-notification. Part of it was already
done in the Netbeans version, so I just completed the c&p from there and
made sure that it behaves exactly the same way as JTree. Doing so, I got
rid off one of the more annoying "features" of a tree: it's tendency to
always collapse a subtree which fired a structureChange. Actually I
think that might be a bug in core: there's a check for sameness which
might be meant to be a check for equality ;-)



*DefaultXOutlineModel*

an implementation which is based on a TreeTableModel. As such it's the
congenial partner of a treeTable, swingx style: it replaces both the
tree-renderer and the TreeTableModelAdapter. In the same way those were,
it is meant as an implementation detail of the treetable. If need be, we
could open it up a bit to allow to plug-in custom implementions of
outlineModel, but wouldn't expect too many implementations - too many
nasty details to think about ;-) For the daring developer, there are
bunches of unit tests to implement against, so go ahead!



*XOutlineEventBroadcaster*

a secret servant of the DefaultX implementation which basically is
responsible to fire tree- and tableEvents on behalf of the outlineModel.
As always the path-to-row conversion is the nasty part, Netbeans
original (EventBroadcaster) got part of it right (particalurly nice: the
mapping of discontigous tree-events to multiple tableEvents). Very
ambitious but not entirely correct was the mapping of expansion change
to insert/delete tableEvents (which SwingX only mapped to dataChanged).
Couldn't resist to take up the challenge <g>


*JXXTreeTable*

it's a c&p'ed JXTreeTable with all tree-renderer references replaced by
XOutlineModel references (and all hacks removed :-). The api didn't
change much (or will not be the end), so I expect a rather smooth
replacement in client code, should be mostly transparent. While not yet
entirely complete, all (okay, can't be sure yet, so let's say most) of
out long-standing issue with selection vanished. Plus the standard
renderers/editors are used - another of our long-standing requirements.


*BasicXX, TreeTableAddon*

belongs into plaf and is meant to be as invisible as possible :-) The
UI-delegate is a subclass of BasicTableUI - and as such not very
extendable (would have to c&p the complete paintXX block just to pass-in
a renderer for the tree cell in that layer), so I opted for just
prefixing the renderer/editor-related parts witn "Basic" to hint at
their potential of being invisible to client code instead of actually
let the delegate control them. The trick right now is in the
JXXTreeTable.getCellRenderer (similar for editor): it passes the
standard renderer over to the BasicXXRenderer for wrapping and return
the BasicXX (works for SwingX style renderers aka componentProvider only)


*XXTest, XXVisualCheck, XXIssues*

those with XX=JXXTreeTable are c&p'd from the corresponding JXTreeTable
- the rename was painless and they  behave well: that's one of the
reasons why I'm fairly confident that replacing our hacky treetable with
the new one will go rather smoothly. And those with XX=XOutlineModel
define its contracts rather completely (okay, not yet - exaggerating as
always <g>)


There's one rather cool design idea in Netbean's default outlineModel
with I didn't yet follow but will soon: the idea is to decorate any
plain ol' TreeModel with the tabular information (they call it
RowModel). Its methods are similar to those which characterize a
TreeTableModel (vs. a TreeModel). That's nice, because then it's
possible to combine a TreeModel implementation (which is painful most of
the time) with multiple RowModels (which is small coin). So I think it
would be worthwhile to add such a pluggable TreeTableModel implemenation
to our SwingX zoo.

Okay, that's for now - feedback highly welcome! In fact, I'm starving
for it: critics, complaints, love messages ... whatever :-)

Enjoy
Jeanette





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

[Kleopatra]

Kleopatra schrieb:
>
>
> As already announced in the other thread:
>
>

forgot the link:

http://forums.java.net/jive/thread.jspa?threadID=42470&tstart=50

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

[jdnc-interest]

I really appreciate the work you do fixing core bugs and promoting correct practices. Thank you.
[Message sent by forum member 'i30817' (i30817)]

http://forums.java.net/jive/thread.jspa?messageID=285485

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

[jdnc-interest]

I downloaded xoutline to have a look but unfortunately it wouldn't compile.
Apart from all the testing stuff, which I can ignore, BasicTreeTablePanel needs changes
made to WrappingIconPanel made on 2008-06-26.
The latest weekly build I can find is for 2008-06-22 on Swinglabs.org.
(On Hudson its 2008-05-18)
I am reluctant to start downloading individual java files, so until (or if :) ) the weekly build is
fixed I am stuck.
[Message sent by forum member 'rturnbull' (rturnbull)]

http://forums.java.net/jive/thread.jspa?messageID=285564

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

[Kleopatra]

Ray,
> I downloaded xoutline to have a look but unfortunately it wouldn't compile.
> Apart from all the testing stuff, which I can ignore, BasicTreeTablePanel needs changes
> made to WrappingIconPanel made on 2008-06-26.
> The latest weekly build I can find is for 2008-06-22 on Swinglabs.org.
> (On Hudson its 2008-05-18)
>  

arrggg ... wasn't aware that Hudson is down ... thanks for the alert!
Just for comparing notes: Hudson and swinglabs.org downloads should have
the same latest successful, which on Hudson has the build #91, done at
22. Jun. 2008 as far as I can see on

http://swinglabs.java.sun.com/hudson/job/SwingX%20Weekly%20Build/

are we talking about the same?
> I am reluctant to start downloading individual java files, so until (or if :) ) the weekly build is
> fixed I am stuck.
>  

well, qualitatively, a weekly is the same as a continous - so you could
declare any of them as your special weekly <g>. But completely
understand your point - would be reluctant myself.

Thanks for trying!
Jeanette

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

[jdnc-interest]

> Just for comparing notes: Hudson and swinglabs.org
> downloads should have
> the same latest successful, which on Hudson has the
> build #91, done at
> 22. Jun. 2008 as far as I can see on
>
> http://swinglabs.java.sun.com/hudson/job/SwingX%20Week
> ly%20Build/

I went to https://swingx.dev.java.net/ and clicked on 'automated builds'
That took me to http://swinglabs.org/hudson/ and the latest Swingx weekly build took
me to http://swinglabs.org/hudson/job/SwingX%20Weekly%20Build/

>
> are we talking about the same?

I don't know :(
[Message sent by forum member 'rturnbull' (rturnbull)]

http://forums.java.net/jive/thread.jspa?messageID=285582

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

[Kleopatra]

jdnc-interest@... schrieb:

>> Just for comparing notes: Hudson and swinglabs.org
>> downloads should have
>> the same latest successful, which on Hudson has the
>> build #91, done at
>> 22. Jun. 2008 as far as I can see on
>>
>> http://swinglabs.java.sun.com/hudson/job/SwingX%20Week
>> ly%20Build/
>>    
>
> I went to https://swingx.dev.java.net/ and clicked on 'automated builds'
> That took me to http://swinglabs.org/hudson/ and the latest Swingx weekly build took
> me to http://swinglabs.org/hudson/job/SwingX%20Weekly%20Build/
>
>  

outch .. that link is outdated (server broken or something)- the new
server is swinglabs.java.sun.com, definitely should update that link
(where's the cleansing boy <g>)

Thanks!
Jeanette

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

[jdnc-interest]

Very happy to see this stuff migrating into JXTreeTable - this is really cool!

A couple of thoughts:
 - There is a general need in Swing for something like outline's RenderDataProvider:  It would be nice to see that survive and even become a general feature of Swing (in my dreams :-)) - that is, if you want to change the painting of a JTree or JList or whatever, usually you just want to replace the icon and the text.  Yet the only way Swing offers to do this is to implement *CellRenderer or subclass Default*CellRenderer.  Anyone who implements the interfaces (most likely over a JLabel) is likely not to know that, for example, you can double the rendering performance by no-opping out firePropertyChange(String, Object, Object) (disables Swing HTML rendering), or to override validate() and other things to be no-ops.  Would make for *much* less work for the common case.

Probably there's more of a case for that to just become a feature of Default*CellRenderer in Swing in some future rev of Swing;  but it certainly would make life easier for the mass of programmers who don't want to deal with the nitty gritty of component painting or cell rendering using JXXTreeTable today.

 - Scott Violet had a look at the Outline code a couple of years ago, and commented that, since an OutlineModel holds layout data, it could not be reused across two components (a thing that, in practice, nobody actually needs - it's just a component hat-trick - but it does prove that the model is really separate).  I think he is correct about that;  if the layout stuff could be moved into a proper UI delegate, that could solve that problem and OutlineModel could be exposed.  Did you do something like that?  Or is XOutlineModel mostly older JXTreeTable code?

 - Giving it a proper UI delegate is good;  I worry a little for the necessary prettification on Mac OS (animated expansion icons and such) and other OS's.  Hopefully if the tree expansion icons are right (easy to get from UIManager), the world will not at least initially notice the rest :-)

Thanks for doing this!  I'm thrilled!

-Tim
[Message sent by forum member 'timboudreau' (timboudreau)]

http://forums.java.net/jive/thread.jspa?messageID=285775

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

[Kleopatra]

Hi Tim,

>  - There is a general need in Swing for something like outline's RenderDataProvider:  It would be nice to see that survive and even become a general feature of Swing (in my dreams :-)) - that is, if you want to change the painting of a JTree or JList or whatever, usually you just want to replace the icon and the text.  Yet the only way Swing offers to do this is to implement *CellRenderer or subclass Default*CellRenderer.  Anyone who implements the interfaces (most likely over a JLabel) is likely not to know that, for example, you can double the rendering performance by no-opping out firePropertyChange(String, Object, Object) (disables Swing HTML rendering), or to override validate() and other things to be no-ops.  Would make for *much* less work for the common case.
>
>  

yeah, agreed - but solved in SwingX and documented in its wiki <g>. In a
short summary: the pluggable parts to change the display of cell content
are called StringValue, IconValue ...(naming does not belong to my
strengths ..;) The collaborator to plug them into is a
ComponentProvider  which takes care of all the dirty details of default
config. This is done once per type of rendering component and later
re-used as-is, for all types of collection components (our
DefaultXXRenderers are mostly glue to legacy code). Special visuals
effects (like differing color, border, font ..) are considered to be
out-of-scope of renderers and applied later in the tree, table, list in
prepareRenderer via Highlighters. So life _is_ easy for SwingX
developers :-)
>  - Scott Violet had a look at the Outline code a couple of years ago, and commented that, since an OutlineModel holds layout data, it could not be reused across two components (a thing that, in practice, nobody actually needs - it's just a component hat-trick - but it does prove that the model is really separate).  I think he is correct about that;  if the layout stuff could be moved into a proper UI delegate, that could solve that problem and OutlineModel could be exposed.  Did you do something like that?  Or is XOutlineModel mostly older JXTreeTable code?
>  

Nitpicking a bit: principally not entirely true - the components would
have the same layout state, similar to  two tables sharing the same
ColumnModel ... not that I would want to do it. Being a separation freak
makes mixing layout and data just a horrible thing to do. So in my
perspective the outlineModel is a slave class doing the hard stuff in
the background (the ui might be a good place for it, we'll see), client
code would not communicate with it. The "model" of a JXTreeTable is a
TreeTableModel (misnomer - this time not mine har, har) which is a
TreeModel with additional per-node columnnar info, the latter being very
similar to Outline's RowModel. This TreeTableModel is what client code
talks with. So I have no intention to expose the outlineModel. And no,
it doesn't contain older treetable code - fortunately, most of that
could be thrown away :-). It's mostly delegate methods to its contained
TreeTableModel and its controllers (which I want to hide as much as
possible, ghastly things are sure to happen if the layout and the
pathSupport get out off synch)
>  - Giving it a proper UI delegate is good;  I worry a little for the necessary prettification on Mac OS (animated expansion icons and such) and other OS's.  Hopefully if the tree expansion icons are right (easy to get from UIManager), the world will not at least initially notice the rest :-)
>
>  
We here at SwingX are accustomed to get bashings for the unpolished
state of new components (the statusbar f.i. hurts the eye in Vista) <g>
> Thanks for doing this!  I'm thrilled!
>
>  

Me too! Wouldn't have done anything without your great break-through, so
a crate of thanks back :-)

CU
Jeanette

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

[Kleopatra]

Ray,
> Apart from all the testing stuff, which I can ignore, BasicTreeTablePanel needs changes
> made to WrappingIconPanel made on 2008-06-26.
>  

just removed that dependency (I plan to replace the WrappingIconPanel
with the BasicTreeTablePanel, names pending, as always ;-) Should
compile now ... at least I hope so.

Cheers
Jeanette

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

[jdnc-interest]

BTW, you mentioned renaming TreePathSupport - I agree - it grew to be more than its name portends.  How about ExpansionModel?  That seems to sum up what it is nicely.

-Tim
[Message sent by forum member 'timboudreau' (timboudreau)]

http://forums.java.net/jive/thread.jspa?messageID=286046

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

[jdnc-interest]

BTW, what of isHtmlDisplayName()?  I'm guessing that will go away...

In all NetBeans trees/tables/lists (the Nodes API provides a common model and you just use a list/tree/table as you need against it, so the code is all in one place), we bypass Swing HTML rendering (don't want to make and throw away a DOM tree for every node during painting for performance reasons) by no-opping firePropertyChange() in our renderers.  Then we use a high-performance (10x faster painting performance than Swing HTML rendering time on an old Ultra 60 when I measured it in '04) HTML renderer that only supports a limited subset of HTML (<b>, <u>, <s>, <i> and various more common SGML entities such as ™, " and a handful of others) and as a further optimization, allow the model to actually specify during rendering whether or not HTML is present.  Also supports non-standard color specification <font color="!controlShadow"> to pull from UIManager color values, which is pretty handy for working with themed UIs to ensure contrasting colors.

The high-speed HTML renderer might be a nice long-term optimization for Swing renderers (probably would have to be turned on explicitly for backward compatibility) - most people aren't embedding images or applets in their cell renderers anyway :-)  Anyway, finding a way to keep that there (or allow the renderer to cast and find it) would make it easier for NetBeans to eventually drop its version of the code and pick up the SwingX version.

Another tweak I'd love to see in JTree/List/Table that goes hand-in-hand with the above is

private boolean firstPaint;

public void updateUI() {
    super.updateUI();
    firstPaint = true;
}

public void paint (Graphics g) {
    if (firstPaint) {
        computeFontSize(g);  //will trigger a repaint
        return;
    }
   super.paint(g);
}

private void computeFontSize (Graphics g) {
    FontMetrics fm = g.getFontMetrics (getFont());
    setFixedCellHeight (Math.max (16, fm.getHeight() + 2); //or equivalent method depending on component, 16 as default icon size but could be fetched from somewhere
}

Thus, after the first paint, all the rows do not need to be iterated to compute preferred size (could also compute it after addNotify() with that hellacious chain of method calls ending in a Graphics from a 1x1 BufferedImage compatible with the graphics device, but, ugh...).

But I digress...

-Tim
[Message sent by forum member 'timboudreau' (timboudreau)]

http://forums.java.net/jive/thread.jspa?messageID=286051

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

[Tim Boudreau]

On Jul 11, 2008, at 1:32 PM, jdnc-interest@... wrote:

> BTW, what of isHtmlDisplayName()?  I'm guessing that will go away...
>
> In all NetBeans trees/tables/lists (the Nodes API provides a common  
> model and you just use a list/tree/table as you need against it, so  
> the code is all in one place), we bypass Swing HTML rendering (don't  
> want to make and throw away a DOM tree for every node during  
> painting for performance reasons) by no-opping firePropertyChange()  
> in our renderers.  Then we use a high-performance (10x faster  
> painting performance than Swing HTML rendering time on an old Ultra  
> 60 when I measured it in '04) HTML renderer that only supports a  
> limited subset of HTML (<b>, <u>, <s>, <i> and various more common  
> SGML entities such as ™, " and a handful of others) and  
> as a further optimization, allow the model to actually specify  
> during rendering whether or not HTML is present.  Also supports non-
> standard color specification <font color="!controlShadow"> to pull  
> from UIManager color values, which is pretty handy for working with  
> themed UIs to ensure contrasting colors.
>
> The high-speed HTML renderer might be a nice long-term optimization  
> for Swing renderers (probably would have to be turned on explicitly  
> for backward compatibility) - most people aren't embedding images or  
> applets in their cell renderers anyway :-)  Anyway, finding a way to  
> keep that there (or allow the renderer to cast and find it) would  
> make it easier for NetBeans to eventually drop its version of the  
> code and pick up the SwingX version.
>
> Another tweak I'd love to see in JTree/List/Table that goes hand-in-
> hand with the above is
>
> private boolean firstPaint;
>
> public void updateUI() {
>    super.updateUI();
>    firstPaint = true;
> }
>
> public void paint (Graphics g) {
>    if (firstPaint) {
>        computeFontSize(g);  //will trigger a repaint
>        return;
>    }
>   super.paint(g);
> }
>
> private void computeFontSize (Graphics g) {
>    FontMetrics fm = g.getFontMetrics (getFont());
>    setFixedCellHeight (Math.max (16, fm.getHeight() + 2); //or  
> equivalent method depending on component, 16 as default icon size  
> but could be fetched from somewhere

firstPaint = false;

Sorry, forgot that.  Also, apologies for the havoc putting HTML inline  
wrought on the forum page - http://forums.java.net/jive/thread.jspa?messageID=286051񅵣 
  - I guess the web view doesn't escape raw HTML :-/

-Tim

>
> }
>
> Thus, after the first paint, all the rows do not need to be iterated  
> to compute preferred size (could also compute it after addNotify()  
> with that hellacious chain of method calls ending in a Graphics from  
> a 1x1 BufferedImage compatible with the graphics device, but, ugh...).
>
> But I digress...
>
> -Tim
> [Message sent by forum member 'timboudreau' (timboudreau)]
>
> http://forums.java.net/jive/thread.jspa?messageID=286051
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@...
> For additional commands, e-mail: jdnc-help@...
>

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

[Kleopatra]

jdnc-interest@... schrieb:
> BTW, what of isHtmlDisplayName()?  I'm guessing that will go away...
>
>  

Hmm .. never considered html in renderers (or anywhere else, always
thought of it like a gimmick without much worth, especially since it
tended to have widely varying appearances across versions ;-) - what do
you need it for and how/when do you "build" it?


Currently SwingX would have a problem with it: StringValue is the
central party responsible  creating a string representation from the
cell value. This string rep is used by:

- the rendering component (or more precisely: the componentProvider
which configures the rendering component) to set an appropriate text
property.

- by matching functionality (pattern-based search, filter highlighting ...)

That's rather straightforward as long as both are considered the same.
With html interfering, they wouldn't. If absolutely necessary, we
probably could find a way, maybe allow a StringValueExt which has the
html producing code additionally and ComponentProviders which are aware
of the fact and use that when configuring the rendering component and
the plain text when serving the matching part.

As to font height - to be honest, I don't understand why you do it that
way: JXTable checks the UIManager for a default fixed rowHeight and
falls back to its getFontMetrics() if nothing found. What's the
advantage of asking the graphics? I mean, that's only the default value
- in custom code with heavy visual decorations there is no way around
iterating through the cells and finding an appropriate height, IMO.


> But I digress...
>
>  

cool - I love digressions to learn from :-)

CU
Jeanette

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

[jdnc-interest]

> With html interfering, they wouldn't. If absolutely
> necessary, we
> probably could find a way, maybe allow a
> StringValueExt which has the
> html producing code additionally and
> ComponentProviders which are aware
> of the fact and use that when configuring the
> rendering component and
> the plain text when serving the matching part.
BTW, this reminds me, what's the state of this?

http://forums.java.net/jive/thread.jspa?messageID=268681񁦉

I just looked and it's probably not good, since I failed to file a bug. :(

Karl
[Message sent by forum member 'kschaefe' (kschaefe)]

http://forums.java.net/jive/thread.jspa?messageID=286408

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

[jdnc-interest]

It seems like breaking the responsibility that StringValue has into two parts could do the trick.  The two roles that this object is serving are: 1) getting a value from the model (the adapter does the actual work, but the StringValue converts type as necessary) and 2) formatting the value obtained in order render the UI.  If you break these two roles apart (but let the user continue to configure both with a single StringValue as the default case) then you can avoid adding an Ext.
[Message sent by forum member 'david_hall' (david_hall)]

http://forums.java.net/jive/thread.jspa?messageID=286418

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

[Tim Boudreau]

On Jul 14, 2008, at 7:43 AM, Kleopatra wrote:

> jdnc-interest@... schrieb:
>> BTW, what of isHtmlDisplayName()?  I'm guessing that will go away...
>>
>>
>
> Hmm .. never considered html in renderers (or anywhere else, always  
> thought of it like a gimmick without much worth, especially since it  
> tended to have widely varying appearances across versions ;-)

You do have to do some magic to avoid getting that darned Serif font :-)

> - what do you need it for and how/when do you "build" it?

You've probably noticed that in NetBeans,