Community
Participate
Working Groups
In our product based on the Eclipse platform we need to customize the text, icons, fonts, and colors displayed in *both* columns of the properties view, but this is currently not supported by the PS. In addition we need to consider the property’s parent in order to properly render some of the properties. We therefore modified the PropertySheetViewer to delegate the rendering of the PS entries to a pluggable ‘widget renderer’, so that users with special needs are free to control the rendering of the (tree item) widget. We added the following interface: public interface IWidgetRenderer { public void render(Widget widget, Object info); } and modified PropertySheetViewer.updateEntry to conditionally invoke the renderer: private void updateEntry(IPropertySheetEntry entry, TreeItem item) { // ensure that backpointer is correct item.setData(entry); if (entry instanceof IWidgetRenderer) ((IWidgetRenderer) entry).render(item, entry); else { // update the name and value columns item.setText(0, entry.getDisplayName()); item.setText(1, entry.getValueAsString()); Image image = entry.getImage(); if (item.getImage(1) != image) item.setImage(1, image); } // update the "+" icon updatePlus(entry, item); } Even though only very minor modifications were made to the org.eclipse.ui.views plugin, we need to clone the plugin every time the Eclipse platform is updated (and this is becoming a maintenance issue). It would be of *great* help to us if this (or similar capabilities) could be included in 3.1. This simple implementation shouldn’t break any existing code or APIs. I have included a patch to the org.eclipse.ui.views plugin, and an example plugin that can be run by importing the widgetrenderer.test plugin into the workspace and then launching a runtime workspace. Create a file with the extension ‘tst’ (e.g. ‘test.tst’), and open the PS view in order to see how the editor’s properties are rendered differently. John
Created attachment 20002 [details] proposed patch to org.eclipse.ui.views plugin
Created attachment 20003 [details] example plugin
See also bug 4584.
It is probably way too late to get anything included in time for the 3.2 release, but I was hoping it would be possible to open up the viewer for extensions ever so slightly, until a more "formal" extension mechanism may be agreed upon. The quick work-around would be for the PropertySheetViewer class to change from 'private' to 'public', and the updateEntry() and updatePlus() methods from 'private' to 'protected'. This would allow us to subclass just the viewer, instead of having to clone & maintain our own version of the complete org.eclipse.ui.views plugin (due to the viewer accessing other private org.eclipse.ui.views classes etc.). Would it be possible to "fast-track" this (simple) change request, so that it may make it in time for 3.2? Thanks, John
John, sorry but we're in 'lock down' mode for 3.2. Also, this is an API change which is something that we just don't do 'ad hoc' because, once published, we have to live with it forever. We'll have to come back to this post-3.2. Do you have any suggestions as what you'd like to see in a more 'formal' extension mechanism?
Eric, the patch I attached earlier is an example of what I meant by a 'formal' extension mechanism (making the viewer class public etc. would be a quicker fix)
The approach outlined in comment#4 would work for us as well (or the IWidgetRenderer approach). We could really use this feature. Is there any problem applying the proposed patch in 3.3?
I'll see if this causes worries but it seems reasonable to me...
Since Eclipse 3.3 is now in milestone 4, I was wondering if it would be possible to apply the method visibility changes (private -> protected) described in comment #4? There's probably still time to consider making more extensive changes as well, but I would very much like to avoid what happened before the last major release (when even simple changes couldn't be applied since the platform was in lock-down status)
John, I apologize for letting this slip off my radar. The new Min/Max behavior has taken over my life...
Eric, would it still be possible to include the (very simple) changes proposed in comment #9 to the 3.3 stream?
(mass update) Removing target milestone, this bug was targeted at a milestone in the past.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
