Home » Eclipse Projects » Eclipse 4 » Selection with tools.compat wrappers
|
| Re: Selection with tools.compat wrappers [message #897275 is a reply to message #897252] |
Mon, 23 July 2012 13:26   |
|
The mixing of 3.x and 4.x plugins/parts is not supported at this time. This is a known limitation of the compatibility layer and is something that is being addressed for the 4.3 release. Until then, due to this issue and several others, unless you implement your own solution it is really an all or none principal (either all 3.x or all 4.x).
If you create your own solution for this problem, the community is always looking for more contributions! 
Take care,
JD
|
|
|
| Re: Selection with tools.compat wrappers [message #897284 is a reply to message #897252] |
Mon, 23 July 2012 13:51 |
Eclipse User |
|
|
|
The context function supplying the selection service (in E4Application.java) creates a selection service for each node that requests it. The aggregation of the selection of these services is done through the SelectionAggregator class (which is in the window context level).
During debugging, can you confirm that (stepping twice inside after setSelection) the value in the context is updated? That is can you separate if the value in the context is not set at all, or it is set and no injection is made?
|
|
| | | | |
| Re: Selection with tools.compat wrappers [message #897569 is a reply to message #897293] |
Tue, 24 July 2012 14:21 |
 Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
I am implementing an e4 view, so i turn I want to avoid dependencies to
3.x (selection provider)
I think I pinned down the issue. The selection aggregator registers
itself at the context of a part, whenever a part is activated.
The problem ist thet the DIViewPart creates a new Context for the View
(not the same as the part itself). Therefore the selection provider of
the view will set SELECTION_OUTPUT in the context of the view, but not
in the context of the part, which is observed by the aggregator.
In other words:
@Inject ESelectionService
service.setSelection(selection);
does not work
context.getParent().set("org.eclipse.ui.output.selection", selection);
this hack works
Is there a specific reason, why the DIViewWrapper creats a new context,
instead of using the Part Context?
Cheers
Jonas
Am 23.07.2012 15:55, schrieb Tom Schindl:
> Well useing ESelectionService is BTW a bad idea because this give you a
> dependency on e4.ui.workbench which ties you to 4.x!
>
> I think that's why I simply added the broker stuff but as said I can't
> remember. Publishing stuff in IEclipseContext is IHMO not solved
> appropriately I've a proposal sometime in 4.0 how this could be fixed
> but it never got implemented.
>
> Tom
>
> Am 23.07.12 15:51, schrieb Tom Schindl:
>> First of all getting different instance of ESelection-Service is
>> expected if I'm not completely mistaken (this will happen in a pure
>> e4-env as well).
>>
>> IIRC i created a special ISelectionProviderService which acts as a
>> broker to publish the selection. It might be better to inject a fixed
>> ESelectionService but it is too long since I worked on it.
>>
>> Tom
>>
>> Am 23.07.12 14:21, schrieb Jonas Helming:
>>> Hi,
>>> I am using the compat DIViewPart implementation form the tools project
>>> to include e4 views into a 3.x application (compat layer). I want to set
>>> and retrieve the selection from two different views. Retrieving the
>>> selection via @named(serviceconstats.activeselection) works fine, as
>>> long as the selection is set by a 3.x view. If I want to set the
>>> selection from a e4 view via @Inject ESelectionService service,
>>> service.setSelection(), the retrieveing views does not get the selection
>>> injected. During debugging, I also found out, the two different e4 views
>>> get different instances of ESelectionService injected.
>>> Any ideas?
>>> Cheers
>>> Jonas
>>
>
|
|
|
| Re: Selection with tools.compat wrappers [message #897576 is a reply to message #897569] |
Tue, 24 July 2012 15:00 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Please do not mix up the ISelectionProvider with
ISelectionProviderService which is from the tools service bundle!
The initial idea of the bridge was that you can target:
* e4
* Eclipse 4.x (the compat layer)
* Eclipse 3.x
That's why there are so called broker services.
Now to your findings: This looks like a bug, when running in Eclipse 4.x
compat layer we don't have to create a context but should simply reuse
the one provided by the compat layer, when running in 3.x we'll have to
create one though.
File a bug, and provide a patch and I'll integrate it. Finding out of
you run in 3.x or 4.x is already done somewhere in the code.
Tom
Am 24.07.12 16:21, schrieb Jonas Helming:
> I am implementing an e4 view, so i turn I want to avoid dependencies to
> 3.x (selection provider)
> I think I pinned down the issue. The selection aggregator registers
> itself at the context of a part, whenever a part is activated.
> The problem ist thet the DIViewPart creates a new Context for the View
> (not the same as the part itself). Therefore the selection provider of
> the view will set SELECTION_OUTPUT in the context of the view, but not
> in the context of the part, which is observed by the aggregator.
> In other words:
> @Inject ESelectionService
> service.setSelection(selection);
> does not work
>
> context.getParent().set("org.eclipse.ui.output.selection", selection);
> this hack works
>
> Is there a specific reason, why the DIViewWrapper creats a new context,
> instead of using the Part Context?
>
> Cheers
> Jonas
>
>
>
> Am 23.07.2012 15:55, schrieb Tom Schindl:
>> Well useing ESelectionService is BTW a bad idea because this give you a
>> dependency on e4.ui.workbench which ties you to 4.x!
>>
>> I think that's why I simply added the broker stuff but as said I can't
>> remember. Publishing stuff in IEclipseContext is IHMO not solved
>> appropriately I've a proposal sometime in 4.0 how this could be fixed
>> but it never got implemented.
>>
>> Tom
>>
>> Am 23.07.12 15:51, schrieb Tom Schindl:
>>> First of all getting different instance of ESelection-Service is
>>> expected if I'm not completely mistaken (this will happen in a pure
>>> e4-env as well).
>>>
>>> IIRC i created a special ISelectionProviderService which acts as a
>>> broker to publish the selection. It might be better to inject a fixed
>>> ESelectionService but it is too long since I worked on it.
>>>
>>> Tom
>>>
>>> Am 23.07.12 14:21, schrieb Jonas Helming:
>>>> Hi,
>>>> I am using the compat DIViewPart implementation form the tools project
>>>> to include e4 views into a 3.x application (compat layer). I want to
>>>> set
>>>> and retrieve the selection from two different views. Retrieving the
>>>> selection via @named(serviceconstats.activeselection) works fine, as
>>>> long as the selection is set by a 3.x view. If I want to set the
>>>> selection from a e4 view via @Inject ESelectionService service,
>>>> service.setSelection(), the retrieveing views does not get the
>>>> selection
>>>> injected. During debugging, I also found out, the two different e4
>>>> views
>>>> get different instances of ESelectionService injected.
>>>> Any ideas?
>>>> Cheers
>>>> Jonas
>>>
>>
>
|
|
|
| Re: Selection with tools.compat wrappers [message #897586 is a reply to message #897576] |
Tue, 24 July 2012 15:40 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
.... and because we are at it. I would advise anyone to stay aways from
the dependencies that come from e4.ui.workbench because this drags i way
too much dependency stuff.
I think we need to find a better and more light weight way to publish
the selection.
I made a suggestion on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=321201 which was not
picked up.
Tom
Am 24.07.12 17:00, schrieb Tom Schindl:
> Please do not mix up the ISelectionProvider with
> ISelectionProviderService which is from the tools service bundle!
>
> The initial idea of the bridge was that you can target:
> * e4
> * Eclipse 4.x (the compat layer)
> * Eclipse 3.x
>
> That's why there are so called broker services.
>
> Now to your findings: This looks like a bug, when running in Eclipse 4.x
> compat layer we don't have to create a context but should simply reuse
> the one provided by the compat layer, when running in 3.x we'll have to
> create one though.
>
> File a bug, and provide a patch and I'll integrate it. Finding out of
> you run in 3.x or 4.x is already done somewhere in the code.
>
> Tom
>
> Am 24.07.12 16:21, schrieb Jonas Helming:
>> I am implementing an e4 view, so i turn I want to avoid dependencies to
>> 3.x (selection provider)
>> I think I pinned down the issue. The selection aggregator registers
>> itself at the context of a part, whenever a part is activated.
>> The problem ist thet the DIViewPart creates a new Context for the View
>> (not the same as the part itself). Therefore the selection provider of
>> the view will set SELECTION_OUTPUT in the context of the view, but not
>> in the context of the part, which is observed by the aggregator.
>> In other words:
>> @Inject ESelectionService
>> service.setSelection(selection);
>> does not work
>>
>> context.getParent().set("org.eclipse.ui.output.selection", selection);
>> this hack works
>>
>> Is there a specific reason, why the DIViewWrapper creats a new context,
>> instead of using the Part Context?
>>
>> Cheers
>> Jonas
>>
>>
>>
>> Am 23.07.2012 15:55, schrieb Tom Schindl:
>>> Well useing ESelectionService is BTW a bad idea because this give you a
>>> dependency on e4.ui.workbench which ties you to 4.x!
>>>
>>> I think that's why I simply added the broker stuff but as said I can't
>>> remember. Publishing stuff in IEclipseContext is IHMO not solved
>>> appropriately I've a proposal sometime in 4.0 how this could be fixed
>>> but it never got implemented.
>>>
>>> Tom
>>>
>>> Am 23.07.12 15:51, schrieb Tom Schindl:
>>>> First of all getting different instance of ESelection-Service is
>>>> expected if I'm not completely mistaken (this will happen in a pure
>>>> e4-env as well).
>>>>
>>>> IIRC i created a special ISelectionProviderService which acts as a
>>>> broker to publish the selection. It might be better to inject a fixed
>>>> ESelectionService but it is too long since I worked on it.
>>>>
>>>> Tom
>>>>
>>>> Am 23.07.12 14:21, schrieb Jonas Helming:
>>>>> Hi,
>>>>> I am using the compat DIViewPart implementation form the tools project
>>>>> to include e4 views into a 3.x application (compat layer). I want to
>>>>> set
>>>>> and retrieve the selection from two different views. Retrieving the
>>>>> selection via @named(serviceconstats.activeselection) works fine, as
>>>>> long as the selection is set by a 3.x view. If I want to set the
>>>>> selection from a e4 view via @Inject ESelectionService service,
>>>>> service.setSelection(), the retrieveing views does not get the
>>>>> selection
>>>>> injected. During debugging, I also found out, the two different e4
>>>>> views
>>>>> get different instances of ESelectionService injected.
>>>>> Any ideas?
>>>>> Cheers
>>>>> Jonas
>>>>
>>>
>>
>
|
|
|
| Re: Selection with tools.compat wrappers [message #899359 is a reply to message #897576] |
Tue, 31 July 2012 14:27 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
done, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=386329
I did not find a Bugzilla component within e4 for the tools...
Am 24.07.2012 17:00, schrieb Tom Schindl:
> Please do not mix up the ISelectionProvider with
> ISelectionProviderService which is from the tools service bundle!
>
> The initial idea of the bridge was that you can target:
> * e4
> * Eclipse 4.x (the compat layer)
> * Eclipse 3.x
>
> That's why there are so called broker services.
>
> Now to your findings: This looks like a bug, when running in Eclipse 4.x
> compat layer we don't have to create a context but should simply reuse
> the one provided by the compat layer, when running in 3.x we'll have to
> create one though.
>
> File a bug, and provide a patch and I'll integrate it. Finding out of
> you run in 3.x or 4.x is already done somewhere in the code.
>
> Tom
>
> Am 24.07.12 16:21, schrieb Jonas Helming:
>> I am implementing an e4 view, so i turn I want to avoid dependencies to
>> 3.x (selection provider)
>> I think I pinned down the issue. The selection aggregator registers
>> itself at the context of a part, whenever a part is activated.
>> The problem ist thet the DIViewPart creates a new Context for the View
>> (not the same as the part itself). Therefore the selection provider of
>> the view will set SELECTION_OUTPUT in the context of the view, but not
>> in the context of the part, which is observed by the aggregator.
>> In other words:
>> @Inject ESelectionService
>> service.setSelection(selection);
>> does not work
>>
>> context.getParent().set("org.eclipse.ui.output.selection", selection);
>> this hack works
>>
>> Is there a specific reason, why the DIViewWrapper creats a new context,
>> instead of using the Part Context?
>>
>> Cheers
>> Jonas
>>
>>
>>
>> Am 23.07.2012 15:55, schrieb Tom Schindl:
>>> Well useing ESelectionService is BTW a bad idea because this give you a
>>> dependency on e4.ui.workbench which ties you to 4.x!
>>>
>>> I think that's why I simply added the broker stuff but as said I can't
>>> remember. Publishing stuff in IEclipseContext is IHMO not solved
>>> appropriately I've a proposal sometime in 4.0 how this could be fixed
>>> but it never got implemented.
>>>
>>> Tom
>>>
>>> Am 23.07.12 15:51, schrieb Tom Schindl:
>>>> First of all getting different instance of ESelection-Service is
>>>> expected if I'm not completely mistaken (this will happen in a pure
>>>> e4-env as well).
>>>>
>>>> IIRC i created a special ISelectionProviderService which acts as a
>>>> broker to publish the selection. It might be better to inject a fixed
>>>> ESelectionService but it is too long since I worked on it.
>>>>
>>>> Tom
>>>>
>>>> Am 23.07.12 14:21, schrieb Jonas Helming:
>>>>> Hi,
>>>>> I am using the compat DIViewPart implementation form the tools project
>>>>> to include e4 views into a 3.x application (compat layer). I want to
>>>>> set
>>>>> and retrieve the selection from two different views. Retrieving the
>>>>> selection via @named(serviceconstats.activeselection) works fine, as
>>>>> long as the selection is set by a 3.x view. If I want to set the
>>>>> selection from a e4 view via @Inject ESelectionService service,
>>>>> service.setSelection(), the retrieveing views does not get the
>>>>> selection
>>>>> injected. During debugging, I also found out, the two different e4
>>>>> views
>>>>> get different instances of ESelectionService injected.
>>>>> Any ideas?
>>>>> Cheers
>>>>> Jonas
>>>>
>>>
>>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 23:07:26 GMT 2024
Powered by FUDForum. Page generated in 0.04029 seconds |
] 
Search
Help
Register
Login
Home
