Just a note, the current set of add-ons for an e4 app:
addons xmi:id=_XGB3wPZlEd-XstlTZ6nTXg
elementId=org.eclipse.e4.core.commands.service
contributionURI=platform:/plugin/org.eclipse.e4.core.commands/org.eclipse.e4.core.commands.CommandServiceAddon/
addons xmi:id=_XGB3wPZlEd-XstlTZ6nTXh
On Tue, Nov 30, 2010 at 10:46 AM, Tom Schindl
tom.schi...@bestsolution.atwrote:
Well this would mean that every addon has to be in itsown bundle but
from my PoV this is fine.
Probably one more note on the current addon-bundle. It has breaking
dependency on org.eclipse.ui which has to be
Not sure I remember Boris and me discovering it at Eclipse Summit Europe
while preparing the hackathon but I don't know if Boris opened a bug for it.
Tom
Am 01.12.10 14:22, schrieb Paul Webster:
On Tue, Nov 30, 2010 at 10:46 AM, Tom Schindl
tom.schi...@bestsolution.at
On Tue, Nov 30, 2010 at 10:30 AM, Eric Moffatt emoff...@ca.ibm.com wrote:
I agree, the 'best practice' for addons should be that the same bundle that
contains the code for the addon should also contain either a fragment or
processor that 'installs' the addon into whatever base model it's
Am 01.12.10 14:27, schrieb Paul Webster:
On Tue, Nov 30, 2010 at 10:30 AM, Eric Moffatt emoff...@ca.ibm.com
mailto:emoff...@ca.ibm.com wrote:
I agree, the 'best practice' for addons should be that the same
bundle that contains the code for the addon should also contain
either
On Wed, Dec 1, 2010 at 8:38 AM, Tom Schindl tom.schi...@bestsolution.atwrote:
Now if you put a commands dependency on bindings and a contexts
dependency on commands. The ModelAssembler guarantees that (see
ModelAssembler#topoSort):
This will get you part of the way there, but really this is
I think we'd better discuss this on IRC but final statement on it but
I'd really like to make sure we are all talking about the same thing.
Problem to solve:
-
Our Workbench Model has to have 2 addons when the workbench is
initialized so that the Addons are processed and start
On Wed, Dec 1, 2010 at 9:55 AM, Tom Schindl tom.schi...@bestsolution.atwrote:
Proposal:
-
Contribute ModelProcessors who add the 2 Addon-Elements = because this
is pure Java you can ensure quite simply that CommandServiceAddon is
before BindingServiceAddon.
I'm not talking about
Ok. Some random thoughts.
a) Our extension points has to have a filter possibility
b) The ModelProcessor is contributed through a fragment
c) The ModelProcessors contributed have check for conditions if they
should contribute
In my opinion MContribution-URIs above bundle boundries is also a
On Mon, Nov 29, 2010 at 11:15 AM, Tom Schindl
tom.schi...@bestsolution.atwrote:
That's not completely true in the our ModelAssembler we do a sorting by
evaluating the dependencies between the contributing bundles.
Model processor is to early in the lifecycle. The addons need a Context to
I did not say that you should install any model listeners in there but
contribute the Addon-Elements to the model instead of requireing the
user to add those addons to their core model.
Tom
Am 30.11.10 13:00, schrieb Paul Webster:
On Mon, Nov 29, 2010 at 11:15 AM, Tom Schindl
Project developer mailing list e4-dev@eclipse.org
Date:
11/30/2010 09:31 AM
Subject:
Re: [e4-dev] Working with modeled UI and HEAD
Sent by:
e4-dev-boun...@eclipse.org
I did not say that you should install any model listeners in there but
contribute the Addon-Elements to the model instead
On Sat, Nov 27, 2010 at 5:05 AM, Tom Schindl tom.schi...@bestsolution.atwrote:
The Addon-Element is generally a problem in this sense. What about the
following.
a) The addons are contributed through a ModelProcessor
b) The model processor checks if there is a tag for the addon in the
Am 29.11.10 17:10, schrieb Paul Webster:
On Sat, Nov 27, 2010 at 5:05 AM, Tom Schindl
tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote:
The Addon-Element is generally a problem in this sense. What about the
following.
a) The addons are contributed through a
Is this the work which removes the need of the. If I get it right ALL
applications who use commands in some way need this.
Wouldn't it be better if they are contributed through a ModelProcess or
once we have our XPath contribution working using a fragment?
What worries me a bit about those
On 23-Nov-2010, at 8:36 AM, Paul Webster wrote:
As part of Bug 329646 [1] I've cleaned up the command lifecycle to use
add-ons to properly integrate with the model. That means an e4 app needs 2
addons in its model to function correctly:
The workbench.swt.cocoa bundle uses a model processor
16 matches
Mail list logo
