[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Question about JFace, wrapped objects, and objectContributions
|
Hi Brian, Hi Michael,
it's not JDT's object contributions that have to be adaptable it's all JDT
actions. We looked into this during the 3.0 time frame and postponed it
(lots of actions, every action implementor as to think about it, not
possible to only do the conversion once). Instead we use two different
approaches depending on whether the selection should only contain the
unwrapped elements or if the wrapped elements are needed as well:
Only unwrapped elements:
======================
We use a special selection provider which does the conversion. You may want
to look at the call hierarchy to see how this works.
Both wrapped and unwrapped elements
==================================
All JDT actions take an IViewSite to access the selection. We have a
special view site (ViewSiteDecorator) which is responsible for converting
the selection. We pass the special view site to the actions which need the
unwrapped elements instead of the one provided by the view itself. The
problem with this approach is that it uses internal API. However we are
working with Platform/UI on an officially supported solution.
HTH
Dirk
Michael Valenta
<Michael_Valenta@
ca.ibm.com> To
Sent by: "Eclipse Platform UI component
platform-ui-dev-b developers list."
ounces@xxxxxxxxxx <platform-ui-dev@xxxxxxxxxxx>
g cc
Subject
24.08.2005 15:59 Re: [platform-ui-dev] Question
about JFace, wrapped objects,
and objectContributions
Please respond to
"Eclipse Platform
UI component
developers list."
<platform-ui-dev@
eclipse.org>
Brian,
The only other option I can think of is for JDT to make their
objectComntributions adaptable. I can't comment on whether they would agree
to do this and it wouldn't help you in the short term anyway. Other than
that, I think 2 would be your best option (although there may be some
gotchas that I don't know about).
The thing that is getting you here is the need to show the same model
object multiple times. If you could get ride of that requirement, you could
just implement a custom content provider (i.e. the intended way to handle
this situation).
Michael
Brian de Alwis
<bsd@xxxxxxxxx>
Sent by: To
platform-ui-dev-bounces@e platform-ui-dev@xxxxxxxxxxx
clipse.org cc
Subject
22/08/2005 04:54 PM [platform-ui-dev] Question about
JFace, wrapped objects, and
objectContributions
Please respond to
"Eclipse Platform UI
component developers
list."
Hi everybody. I have a question about the interaction of
objectContributions and selections when dealing with custom models
managed through JFace. My apologies if this isn't seen as appropriate
for this list, but it seemed that there is a deeper issue here.
I'm using a JFace TreeViewer to provide a view on a model. As my
model doesn't directly correspond to a tree, I've created a projection
of the model using a structure similar to the TreeParent / TreeObject
as provided by the JFace generated templates. I've modified my
LabelProvider to unwrap these objects appropriately.
My problem is this: although my wrappers are an internal thing,
meant only to impose a structure, they are bleeding through, becoming
the actual objects exposed to the workbench. As a result, some of
the workbench's objectContributions are not being properly applied,
such as when building context menus.
For example, some of my model objects are actually JDT IJavaElements.
But because the JDT objectContributions don't specify "adaptable=true"
(e.g. org.eclipse.jdt.internal.ui.compare.JavaReplaceActions and
org.eclipse.jdt.internal.ui.compare.JavaCompareActions), they never
appear in the context menus, even when the wrappers can be adapted.
I think they should apply as my wrapper objects exist only to
support imposing a viewing structure; the `real' objects are the
model objects.
I can't return the actual model objects (e.g. the IJavaElements),
as they may occur multiple places in my model (which causes problems
with implementing ITreeContentProvider.getParent()).
I see three solutions to this problem, but I'm hoping there is a
better way?
1. My hacked solution for the moment is to explicitly call
ObjectActionContributorManager.contributeObjectActions() in in
my menuAboutToShow(IMenuManager) callback and provide an
explicitly unwrapped selection. This solves the immediate
problem, but it's an undesirable, short-term solution.
2. Subclass TreeViewer and override the getSelection() to do the
rewrapping. This seems the better immediate option, but I'm
not sure about the consequences, and the same problem will occur
with other types of structured viewers.
3. Add another level of indirection with an additional method to
IStructuredContentProvider.getModelObject(), called appropriately?
I apologize if this has been discussed before, but I couldn't find
anything appropriate.
Brian.
--
Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/
"There is much pleasure to be gained in useless knowledge." - Bertrand
Russell
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
