Community
Participate
Working Groups
GEF currently copies the implementation of PropertySheetEntry. Our clients then in turn copy our implementation. The result is that fixes in the base implementation will never find there way down into real application code. Similarly, bug reporting will be subject to the trickle-down effect too.
Copying code is not good in general. Speak with Adrian about this for details :- )
Please consider this for 3.0. The API has not changed in 4 releases.
Randy, nobody on the UI team is actively working on the properties view, or has the cycles to look at this for M9. Making this API will require more thought than just flipping the visibility of the class to public. Would you like to look into this and contribute a patch?
Done.
Created attachment 10573 [details] Changes to PropertySheetEntry API In order for GEF to subclass PropertySheetEntry, we need the changes in this Patch to be applied. Otherwise, we'd have to continue to copy/paste the code. This is the minimal amount of changes necessary for us to make use of the API in our UndoablePropertySheetEntry class.
Sorry, we're now feature and API frozen for 3.0. If a patch had been provided when first requested, it might have made it. Will consider post-3.0.
Also, please don't mark bugs as critical unless they're stop-ship bugs.
Sorry Nick, the severity was marked critical in early 3.0 development, not recently. We got burnt for having a copy because there was a bug fixed in the original.
when making PropertySheetEntry API please don't forget about #1883 and at least open some hooks (i.e. make computeMergedPropertyDescriptors() protected add a new sortPropertyDescriptors() and call it from computeMergedPropertyDescriptors())
Reopening for 3.1 consideration
Would really like to get rid of our local copy of this class.
Randy, are you OK with the patch?
I'll have to trust Whitney on this one. Our implementation has not changed much since he went back to school, so the patch should still meet our needs.
I'm reviewing the patch now. It looks like createChildEntries(int) isn't necessary. I can't see why you'd need to override the type of the array, just the type of the elements. Randy, can you confirm?
That makes sense to me. Perhaps that's an artifact of having copied the entire class at one point.
Actually, I've applied the more recent patch in bug 24694. Please follow up there. *** This bug has been marked as a duplicate of 24694 ***
The patch included making setValue(Object) protected so that we could override that method. I may have a workaround
I can still add it if you want.
I don't need it. I actually deleted several lines by overriding a different method instead.
