| org.eclipse.ui.views.properties: PropertySheetPage and PropertySheetViewer much less extensible than [message #294179] |
Fri, 04 November 2005 17:42  |
Eclipse User |
|
|
|
It's a pity, that the classes
org.eclipse.ui.views.properties.PropertySheetPage and
org.eclipse.ui.views.properties.PropertySheetViewer were not written
with more extensibility in mind!
E.g. I would like to define a few more PropertyDescriptor classes that
would allow to display certain properties not as strings but using some
graphical feedback, like indicating a color directly via some spot in
that color (instead of displaying some "RGB{x, y, z}" string or using
some icon instead of a text string, etc.
All it would need to be able to do this would be the possibility to
overwrite the method
PropertySheetViewer.updateEntry(IPropertySheetEntry, TreeItem).
However, that method and several methods up the calling chain are all
declared as private, the class itself is package visible only, and
PropertySheetPage even directly creates the PropertySheetViewer via new
in method createControl() instead of using some createViewer() method,
that one could overwrite. So in order to overwrite just that specific
method I would have to duplicate and replace the entire
PropertySheetPage handling and a HUGE hierarchy, at least half the
package!
It's almost, as if someone voluntarily tried hard to prevent developers
from being able to extend anything from this package! Why is this so
much less flexible than it could be??? Sigh!
Michael
|
|
|
| Re: org.eclipse.ui.views.properties: PropertySheetPage and PropertySheetViewer much less extensible [message #294180 is a reply to message #294179] |
Fri, 04 November 2005 18:04  |
| Eclipse User |
|
|
|
I just posted a patch yesterday to the EMF newsgroup and to bug 108470
that contains a custom (copied) DetailsSheetViewer based on
PropertySheetViewer that you could use as the basis for your custom
property handling. I suppose you'd have to reinvent the whole Property
View to do what you want though. Perhaps we should open an item asking
for PropertySheetPage and friends to be made public?
-
Steve
Michael Moser wrote:
> It's a pity, that the classes
> org.eclipse.ui.views.properties.PropertySheetPage and
> org.eclipse.ui.views.properties.PropertySheetViewer were not written
> with more extensibility in mind!
>
> E.g. I would like to define a few more PropertyDescriptor classes that
> would allow to display certain properties not as strings but using some
> graphical feedback, like indicating a color directly via some spot in
> that color (instead of displaying some "RGB{x, y, z}" string or using
> some icon instead of a text string, etc.
>
> All it would need to be able to do this would be the possibility to
> overwrite the method
> PropertySheetViewer.updateEntry(IPropertySheetEntry, TreeItem).
>
> However, that method and several methods up the calling chain are all
> declared as private, the class itself is package visible only, and
> PropertySheetPage even directly creates the PropertySheetViewer via new
> in method createControl() instead of using some createViewer() method,
> that one could overwrite. So in order to overwrite just that specific
> method I would have to duplicate and replace the entire
> PropertySheetPage handling and a HUGE hierarchy, at least half the package!
>
> It's almost, as if someone voluntarily tried hard to prevent developers
> from being able to extend anything from this package! Why is this so
> much less flexible than it could be??? Sigh!
>
> Michael
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.02895 seconds
Home