[
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
|
Micheal,
I was anticipating that Brian wants to get all JDT actions not only those
that are contributed via the object contribution extension point (only
having Java compare actions and not the Refactoring and Source actions in
the context menu didn't make to much sense for me ;-)). Almost all JDT
actions aren't contributed via extension points. To be able to have these
actions on the wrapper objects as well the JDT actions have to be prepared
for this or as outlined in the other messages some converter/delegate has
to convert the selection before it gets actually passed to the actions.
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 05:47 Re: [platform-ui-dev] Question
PM about JFace, wrapped objects,
and objectContributions
Please respond to
"Eclipse Platform
UI component
developers list."
<platform-ui-dev@
eclipse.org>
Dirk,
I'm not sure why you say that all JDT actions needs to be adaptable and not
just those that are objectContributions. I think perhaps you are addressing
a broader problem than I was describing. Currently, if I put a java model
element in one of my views and register my context menu with the workbench,
I will only get the objectContributions showing up in my popup menu (I
assume that Brian has tried this and got a subset of the JDT actions). Any
JDT actions that are not objectContributions will not appear. These object
contributions that do appear shouldn't have any requirements on the view
from which they originated (although they could I suppose). With the new
support for objectContribution adaptability added in 3.1, you could add the
adaptable=true flag to the JDT objectContributions and they should appear
on the wrappedObjects as long as they adapt to a Java model element (this
won't work in 3.0 or prior as only adaptablilty of IResource was
supported).
Anyway, I wasn't mentioning this as the most viable solution. I actually
think it is one we sould avoid if possible because there are many pitfalls
(i.e. how do you deal with mappings that are not one-to-one). My prefered
solutions would be to use the approach Markus suggested (which I didn't
know about. Thank's for the tip Markus). This seems like the intended
mechanism for this case. Of course, it is possible that Brian would want
access to the additional JDT actions but I'll leave that to him to discuss.
Michael
Dirk Baeumer
<dirk_baeumer@xxxxxx.
com> To
Sent by: "Eclipse Platform UI component
platform-ui-dev-bounc developers list."
es@xxxxxxxxxxx <platform-ui-dev@xxxxxxxxxxx>
cc
"Eclipse Platform UI component
24/08/2005 11:17 AM developers list."
<platform-ui-dev@xxxxxxxxxxx>,
platform-ui-dev-bounces@xxxxxxxxxxx
Please respond to Subject
"Eclipse Platform UI Re: [platform-ui-dev] Question about
component developers JFace, wrapped objects, and
list." 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
_______________________________________________
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
