Currently PropertyPanels are embedded in the
PropertySheet as a
means of displaying properties.
Once the propertysheet rewrite is completed,
be rewritten to invert this relationship
dependencies on old GUI classes like SheetButton).
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
FYI, when you open the layer widget, the following code
is called for each instance:
Class c = pm.getPropertyEditorClass();
java.lang.reflect.Constructor con = c.getConstructor(new
currEditor = (PropertyEditor) con.newInstance(new Object
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
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
- 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
- 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
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:
cvs update -r proppanel_rewrite2
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
NB_SRC/openide/src/org/openide/explorer/view/ - branch proppanel_rewrite2
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 panel branch integrated into trunk.