Home » Eclipse Projects » Eclipse 4 » Selection with tools.compat wrappers
| Selection with tools.compat wrappers [message #897252] |
Mon, 23 July 2012 08:21  |
Eclipse User |
|
|
|
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 #897569 is a reply to message #897293] |
Tue, 24 July 2012 10:21  |
| Eclipse User |
|
|
|
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 11:00 |
| Eclipse User |
|
|
|
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 11:40 |
| Eclipse User |
|
|
|
.... 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 10:27 |
| Eclipse User |
|
|
|
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: Wed Jul 23 06:09:22 EDT 2025
Powered by FUDForum. Page generated in 0.33724 seconds |
Home
