Bug 31896 - Rewrite PropertyPanel to use infrastructure from new PropertySheet
Rewrite PropertyPanel to use infrastructure from new PropertySheet
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Explorer
3.x
All All
: P3 (vote)
: TBD
Assigned To: _ tboudreau
issues@platform
ws2fcs
: UMBRELLA
Depends on: 29447 37626
Blocks: 9691 17510 19266 19527 21686 22996 24964 26367 29612 31807 33023 34163 34169 34170 34172 34173 34177 34178 35083 35534 35539 36026 36304 36410 36421 36608 36613 36708 36719 36723 36801 36802 36829 37057 37186 37337 37360 37448 37575 37673 37721 37743 37835 37838
  Show dependency treegraph
 
Reported: 2003-03-11 15:40 UTC by _ tboudreau
Modified: 2008-12-22 19:35 UTC (History)
5 users (show)

See Also:
Issue Type: TASK
:


Attachments
Final diff before merge (188.62 KB, application/octet-stream)
2003-12-08 22:58 UTC, _ tboudreau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2003-03-11 15:40:30 UTC
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.
Comment 1 _ tboudreau 2003-04-24 14:15:27 UTC
Created branch proppanel_issue_31896 for directory
openide/src/org/openide/explorer/propertysheet off branch 
propsheet_issue_29447
Comment 2 _ tboudreau 2003-04-25 00:43:27 UTC
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.
Comment 3 _ tboudreau 2003-06-25 23:56:51 UTC
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.
Comment 4 _ tboudreau 2003-10-03 09:05:09 UTC
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).
Comment 5 _ tboudreau 2003-10-07 19:13:43 UTC
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.
Comment 6 _ tboudreau 2003-10-13 08:29:57 UTC
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.
Comment 7 _ tboudreau 2003-11-11 10:31:18 UTC
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.
Comment 8 _ tboudreau 2003-11-29 10:50:14 UTC
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
Comment 9 _ tboudreau 2003-12-08 12:09:33 UTC
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?
Comment 10 Jiri Skrivanek 2003-12-08 12:17:29 UTC
Yes, that's right.
Comment 11 Rochelle Raccah 2003-12-08 21:56:24 UTC
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.
Comment 12 _ tboudreau 2003-12-08 22:58:43 UTC
Created attachment 12472 [details]
Final diff before merge
Comment 13 _ tboudreau 2003-12-08 23:00:48 UTC
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.
Comment 14 _ tboudreau 2003-12-09 09:32:52 UTC
Property panel branch integrated into trunk.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo