Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (497)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  JTree, grrr...  (Read 2712 times)
0 Members and 1 Guest are viewing this topic.
Offline ryanm

Senior Member


Projects: 1


Used to be bleb


« Posted 2003-12-11 10:49:07 »

Not strictly game related, but anyhoo...

I have a JTree and a JList that contain the same sorts of things, and so i have implemented a common cell renderer.

The problem is that the cell sizes are being limited by the JTree and JList so that, with a non-12 point font and plain style, the text is cut off.

For example: with a 12 point font, everything is:
<previously an image of a tree>

But when we try to use a bold, 24 point font in a fetching red hue, disaster strikes!
<previously an image of an ugly tree>

As can be seen, the cells are limited as though they contained standard, 12-point text.

The tree will limit the cells in width and height, whereas the list is slightly better behaved, limiting only the height.

Trying getLayout() on JTree returns null, so it's difficult to find what is actually doing the layout, and presumably the limiting.

Does anybody have any hints on how to get JTrees and JLists to loosen up a bit?
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2003-12-11 11:54:29 »

I have encountered a very similar thing. I think this is a major bug in JTree.

I return components with size, preferred size, and minimum size all EXPLICITLY set correctly for the font size.

All nodes with the root as parent work perfectly

All branch nodes work perfectly ONCE you have expanded them

All other nodes JTree completely inexplicably artificially resizes them (somehow side-stepping the setsize and getsize etc methods, which I've overridden to try and prevent it - although I haven't yet checked that I've overrided EVERY possible method, I migth have missed some!) as follows:

Each node gets resized to the dimensions of the FIRST branch node which IMMEDIATELY follows the branch node which is the parent of the current node.

If you have any sugestions, I'd love to hear them...

EDIT: I'm not even using Label's at all, so it's unrealted to them. I have extended JComponent so I can use the full power of J2D in my rendering (only using fancy fonts so far...)

malloc will be first against the wall when the revolution comes...
Offline ryanm

Senior Member


Projects: 1


Used to be bleb


« Reply #2 - Posted 2003-12-11 12:19:35 »

Quote
... size all EXPLICITLY set correctly for the font size.


So that means:

1  
2  
3  
4  
5  
6  
JComponent jc = // generate it here

jc.setMinimumSize( jc.getSize() );
jc.setPreferredSize( jc.getSize() );

return jc;


works, at least to an extent, which implies that whatever is laying out the tree pays attention to the min or preferred size...
eeeenteresting...

Another issue is that, although the JList honours each cell's width in that the entire length will be painted, it does not take into account the font size when determining whether or not to display scrollbars.

Methinks some naughty/lazy programmer in Sun has hardcoded 12-point fonts into the API.

I'm rapidly coming to agree with your hardline "Complete JTree replacement" viewpoint.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2003-12-11 12:34:55 »

Quote


So that means:

1  
2  
3  
4  
5  
6  
JComponent jc = // generate it here

jc.setMinimumSize( jc.getSize() );
jc.setPreferredSize( jc.getSize() );

return jc;



I currently calculate the appropriate size by hand, based on font metrics - future revisions will need to contain arbitrary Shape's at arbitrary transforms, so I need to be a bit more general Smiley...

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2003-12-11 12:40:46 »

Quote


works, at least to an extent, which implies that whatever is laying out the tree pays attention to the min or preferred size...
eeeenteresting...


My suspicion currently is that it's part of the "high performance optimizations" that made it into Jtree over time (an example of the hackery that has gone on with this class).

I think they're "optimizing" the area painted for each node by looking at what nodes are already visible - and possibly the intention was to use the size of the PARENT node as the size for the child nodes, but an "out-by-one" error meant they ref the size of the sibling node immediately following the parent.

As I mentioned before, JTree kind of works - the perf optimizations do their job well for huge jtree's (and on their own they are well designed AFAICS), but they are imperfect, poorly integrated into the class, and cause extra bugs (typical symptoms of hack-it-and-see development process; also one of the things OO seeks to avoid!). Although they can work excellently, Jtree's optimizations are so coarse-grained as to be insufficient in some common environments where huge jtree's exist.

malloc will be first against the wall when the revolution comes...
Offline ryanm

Senior Member


Projects: 1


Used to be bleb


« Reply #5 - Posted 2003-12-11 12:46:07 »

Quote
I currently calculate the appropriate size by hand

I was afraid of that.  I would very much like to avoid messing around with FontMetrics and the like.

Are you sure you actually have to calculate the correct size by hand?  From what i can see the Components are the correct size when they leave the CellRenderer, they just get borked when the JTree gets hold of them.

I've posted to the JavaDesktop forum as well, but no replies so far...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #6 - Posted 2003-12-11 12:46:53 »

The size of a row in a JTree is set somewhere else, in fact I think that there is a setting that says if all rows are the same height...
hmm.. maybe not.. but I did find this:
JTree.setRowHeight();

Of course - it looks like the height bit is working for you anyway...  You probably need a custom cell renderer.. That's easy enough to do.

Have you stepped through the rendering code into the guts of JTree so you can see how it is working?

Offline ryanm

Senior Member


Projects: 1


Used to be bleb


« Reply #7 - Posted 2003-12-11 13:49:25 »

Quote
it looks like the height bit is working for you anyway


I'm afraid it isn't, if you look at the "java" in the picture, it appears to start with an "i".  The height cropping is just not readily apparent from the picture i gave.

Quote
but I did find this:
JTree.setRowHeight();


hmmm... the javadoc says
Quote
If the specified value is less than or equal to zero the current cell renderer is queried for each row's height.


Which might be what I'm looking for.  There's no corresponding setWidth() method though...

Quote
You probably need a custom cell renderer

ahem
Quote
i have implemented a common cell renderer


I'd really rather not get into the guts of the JTree implementation.  What I'm trying to achieve is not a particularly outlandish or complex thing.  All i expect the JTree to do is respect the preferred sizes of the cell components, instead of forcing them to the size they would be if they used 12-point text.

<late breaking news>
using tree.setRowHeight( -1 ) almost works.

1) you set the font to be huge ( ~60 )
2) the tree element disappear
3) they reappear when they are opened/closed
4) Cheesy
5) you set the font to be normal ( 12 )
6) the tree elemnts resize themselves back to 12...
7) ... but with huge, 60-point gaps between each element  Angry

tinkering will continue...
Offline ryanm

Senior Member


Projects: 1


Used to be bleb


« Reply #8 - Posted 2003-12-11 14:15:31 »

Found a solution Cheesy

Well, those nice folks over at the JavaDesktop forums did anyway...

It seems that the JTree's internal cache is flushed when you set a new Renderer, so everytime you make a change to the size of your cells, just call

tree.setRenderer( null );
tree.setRenderer( yourRenderer );

There's probably a way to avoid having to re-evaluate every cell, but that'll do for now.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2003-12-12 15:26:37 »

Quote

It seems that the JTree's internal cache is flushed when you set a new Renderer, so everytime you make a change to the size of your cells, just call


I'm not changing the size of my cells, I'm correctly assigning them at creation time, so I'm not sure this will help.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2003-12-12 15:28:56 »

Quote
The size of a row in a JTree is set somewhere else, in fact I think that there is a setting that says if all rows are the same height...
hmm.. maybe not.. but I did find this:
JTree.setRowHeight();


Yeah, with positive rowheight the height of components certainly should be ignored by Jtree (although this is an example of where the API is not a great tree component...).

My problem is that the one thing that components MUST set themselves (the width - because Jtree does not HAVE a width, it calculates it according to the widths of the displayed components, so that it can work properly with a scrollpane etc. At least, AFAICS...) is being knocked out by Jtree in the cases I outlined Sad.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2004-01-07 09:58:48 »

Quote

I'd really rather not get into the guts of the JTree implementation.  What I'm trying to achieve is not a particularly outlandish or complex thing.  All i expect the JTree to do is respect the preferred sizes of the cell components, instead of forcing them to the size they would be if they used 12-point text.

<late breaking news>
using tree.setRowHeight( -1 ) almost works.

1) you set the font to be huge ( ~60 )


FYI, how *exactly* are you setting font-size?

malloc will be first against the wall when the revolution comes...
Offline ryanm

Senior Member


Projects: 1


Used to be bleb


« Reply #12 - Posted 2004-01-07 10:17:07 »

There are three categories of items that can be in the tree, and each category has an associated java.awt.Font object, aswell as a background and foreground colour.  The renderer just uses JComponent.setFont(), .setForeground() and .setBackground() on the JLabel i am using to display the item, according to the item's category.

Each category's membership is defined by a series of restricted regular expressions, so every time the expressions are changed, i just have to flush the JTree's cache with the setRenderer( null ); setRenderer( myRenderer ); trick, and it all works out lovely.

On a side note, doesn't FYI mean "for your information"?
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #13 - Posted 2004-01-07 12:16:20 »

Quote

On a side note, doesn't FYI mean "for your information"?


Yeah, I meant "FOI" (our) Smiley

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (11 views)
2014-04-15 18:08:23

BurntPizza (10 views)
2014-04-15 03:46:01

UprightPath (23 views)
2014-04-14 17:39:50

UprightPath (10 views)
2014-04-14 17:35:47

Porlus (27 views)
2014-04-14 15:48:38

tom_mai78101 (49 views)
2014-04-10 04:04:31

BurntPizza (107 views)
2014-04-08 23:06:04

tom_mai78101 (207 views)
2014-04-05 13:34:39

trollwarrior1 (176 views)
2014-04-04 12:06:45

CJLetsGame (182 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!