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.
Currently PropertyPanels are embedded in the PropertySheet as a means of displaying properties. Once the propertysheet rewrite is completed, propertyPanel should be rewritten to invert this relationship (eliminates final dependencies on old GUI classes like SheetButton). Instead, PropertyPanel should use the lightweight rendering infrastructure from the new property sheet.
Created branch proppanel_issue_31896 for directory openide/src/org/openide/explorer/propertysheet off branch propsheet_issue_29447
FYI, when you open the layer widget, the following code is called for each instance: Class c = pm.getPropertyEditorClass(); try { java.lang.reflect.Constructor con = c.getConstructor(new Class[0]); c.setAccessible (true); currEditor = (PropertyEditor) con.newInstance(new Object [0]); This can hardly be efficient. FWIW I'm doing a trial run of adapting PropertyPanel to use the new propertysheet rendering infrastructure - JTable style lightweight renderers, etc. So far it doesn't do much but throw exceptions, but it looks like it will eventually work.
This should be postponed pending repackaging of PropertySheet and a revised/new API for property support; the alternative is lots of horrible hacks to make the rendering infrastructure work with Node.Property-less DefaultPropertyModel.
FWIW, I've got a pseudo-replacement working, but non-public - but it doesn't support the full API of PropertyPanel (support for PropertyModel, etc.). So the question is, should we: - Make it public and deprecate PropertyPanel as a whole or - Try to shoehorn it into PropertyPanel when PropertyPanel is in non- custom editor mode? I'm more in favor of option 2, as it would allow us to cleanly deprecate the whole PropertyModel attempt which didn't really work out (anything you can do with DefaultPropertyModel [reflection based driving of a PropertyPanel] you can also do with PropertySupport.Reflection - so we never really needed two ways to do the same thing).
I've got a property panel rewrite working and passing its unit tests - see the branch proppanel_rewrite (only the org/openide/explorer/propertysheet directory is branched). Still a bit to do, re making sure the whole isChangeImmediate shebang works & making the UI look nice both in tree tables and when just embedded in a panel. The new PropertyPanel involves the following changes: - It is now driven by Node.Property objects - under the covers, when it is given a PropertyModel, it either finds or constructs an appropriate Node.Property - It embeds an instance of PropertyRenderer if it is in non-custom editor mode. PropertyRenderer uses the property sheet's rendering infrastructure for rendering and editing properties, so it's consistent with the property sheet and very lightweight - PropertyRenderer doesn't actually even contain any child components unless it has focus and the user is editing, but like the property sheet, there's no visible difference between the two states unless the property editor paints itself.
FYI, I tried patching TTV to use a single PropertyPanel to paint all the values. It works, but there are some problems on the Import Management Tool's final screen - all of the properties end up reflecting whatever the value for the first property is. I'm not sure what's going on there; it may have to do with the order changes get fired in - OR, the property editor there may be directly updating the underlying property, or they may be sharing a single property editor instance or something - I didn't investigate further.
FYI, to try the latest property panel rewrite branch: cd $NB_SRC/openide/src/org/openide/explorer/propertysheet cvs update -r proppanel_rewrite2 cd ../view cvs update -r proppanel_rewrite2 It is working and behaving well, any feedback is appreciated. Merging with the trunk is postponed until after winsys2 merge & stabilization.
In preparation for the merge, I've merged the proppanel_rewrite2 branch back to its parent branch proppanel_rewrite. So, to test the changes now, you want NB_SRC/openide/src/org/openide/explorer/propertysheet/ - branch proppanel_rewrite NB_SRC/openide/src/org/openide/explorer/view/ - branch proppanel_rewrite2 NB_SRC/openide/test/unit/src/org/openide/explorer/propertysheet - branch proppanel_rewrite 2
FYI, merge of the branch is now planned for TOMORROW MORNING. That's December 9, 2003. I will merge the changes to Jelly at the same time. Jirka, I'm assuming the jelly Property class is still the only one changed - that's right, right?
Yes, that's right.
Tim, please remember to also do whatever process Jiri does to update the jar in the builds directory. I think there's some version number file in addition to the actual jar.
Created attachment 12472 [details] Final diff before merge
Attached what should be a final diff (assuming nobody commits anything that conflicts in the next 10 hours or so). I will integrate this tomorrow morning from home, then come to the office and see if anything exploded :-) Jiri, I don't know what you do to update the Jelly jar (boy does that sound silly). So, do what you need to do. I'll commit the update to Property.
Property panel branch integrated into trunk.