This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Collumn chooser is sometimes displayed in the upper right corner of the TreeTableView. I have a quiz for you: what is the API to display it? (Note: if you look at the sources you will probably find out, but I am not that quick as you and it took me more than 10 minutes to find it). Also even if you know - it is not correct IMHO to use unrelated constants the way they are used there. Also please check issue #37099 what other side effect this "API" has.
At least document in http://www.netbeans.org/download/dev/javadoc/OpenAPIs/arch/openide-explorer.html#group-property right now there is an API mentioned, but is not at all documented.
Wow, Davide, you can control this button by VerticalScrollBar policy, if it's set to JScrollPane.VERTICAL_SCROLLBAR_ALWAYS then this button is visible, if it's set on other value then this button isn't visible. Cool! More contracts such this :) Do you propose add a method to control this button? Or wait for rewrite this component? The second is better for me.
I did not know your were planning to rewrite the whole component. If you can get it into 3.6 - it is fair to wait. But if it is faaar in the future I suggest to add the method for 3.6. still.
Sorry, David, I just inherited this charming component, and strange APIs don't rank as P2s in my world, only broken ones :-) And, hey, it only took 10 minutes to find! That's not bad at all. Seriously, this component *will* get a rewrite.
Ok - I did not know about 33281 and that you are going to rewrite it. In such case just don't forget about his issue - you may even close it you are going to write it from scratch. Or better yet just do not copy the strange logic from the old impl and provide something normal. Good luck.
The Tasklist guys (Tim Lebedkov) already have a replacement I'm going to evaluate. I think to do it really right, you need a TableModel a TreeModel can be plugged into - but that means I get to write all of the expanded state tracking stuff that lives in JTree myself. There are some classes that could help (FixedHeightLayoutCache, et. al.), but it would still be at least a month's work. What they did is based more on some SwingConnection article, which still embeds a JTree, just does it in a less wildly wacky way than ours. Not sure how it scales, but if it drops in without too much pain, I may just go for it - anything would be an improvement.
not a regression -> switching issue type to 'enhancement'
TTV is being replaced with outlineview, closing