Re: [e4-dev] Working with modeled UI and HEAD
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 elementId=org.eclipse.e4.ui.contexts.service contributionURI=platform:/plugin/org.eclipse.e4.ui.services/org.eclipse.e4.ui.services.ContextServiceAddon/ addons xmi:id=_XGB3wPZlEd-XstlTZ6nTXi elementId=org.eclipse.e4.ui.bindings.service contributionURI=platform:/plugin/org.eclipse.e4.ui.bindings/org.eclipse.e4.ui.bindings.BindingServiceAddon/ addons xmi:id=_LK0NgPZmEd-XstlTZ6nTXj elementId=org.eclipse.e4.ui.workbench.commands.model contributionURI=platform:/plugin/org.eclipse.e4.ui.workbench/org.eclipse.e4.ui.internal.workbench.addons.CommandProcessingAddon/ addons xmi:id=_LK0NgPZmEd-XstlTZ6nTXk elementId=org.eclipse.e4.ui.workbench.contexts.model contributionURI=platform:/plugin/org.eclipse.e4.ui.workbench/org.eclipse.e4.ui.internal.workbench.addons.ContextProcessingAddon/ addons xmi:id=_LK0NgPZmEd-XstlTZ6nTXl elementId=org.eclipse.e4.ui.workbench.bindings.model contributionURI=platform:/plugin/org.eclipse.e4.ui.workbench.swt/org.eclipse.e4.ui.workbench.swt.util.BindingProcessingAddon/ On top of that, 3 model processors have been added to org.eclipse.ui.workbench for the compatibility layer (you get these 3 for free): processor beforefragment=true class=org.eclipse.ui.internal.CommandToModelProcessor /processor processor beforefragment=true class=org.eclipse.ui.internal.ContextToModelProcessor /processor processor beforefragment=true class=org.eclipse.ui.internal.BindingToModelProcessor /processor Later, PW -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 fixed anyways! Do we have a bug for that? It's probably the binding processing ... that can be moved to the e4 swt plugin. PW -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 mailto:tom.schi...@bestsolution.at wrote: 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 fixed anyways! Do we have a bug for that? It's probably the binding processing ... that can be moved to the e4 swt plugin. PW -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindlgeschaeftsfuehrer/CEO eduard-bodem-gasse 5/1A-6020 innsbruck phone++43 512 935834 ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 applied to (I think it's Lars or Tom that came up with this one but I like it...;-). [... snip ...] Can we do it this way Paul ? Not without chicanery. Bundle fragments are processed in arbitrary order. The addons have to be added in a specific order. Command service, context service, binding service. Then command processing, context processing, binding processing. Commands are a standalone service, as are contexts. Each binding addon depends on the matching commands/contexts addon having already been run. PW -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 a fragment or processor that 'installs' the addon into whatever base model it's applied to (I think it's Lars or Tom that came up with this one but I like it...;-). [... snip ...] Can we do it this way Paul ? Not without chicanery. Bundle fragments are processed in arbitrary order. The addons have to be added in a specific order. As stated before this is NOT true. There is a rule in which the ModelAssembler process them. if we have e.g. 3 bundles: org.eclipse.e4.contexts org.eclipse.e4.commands org.eclipse.e4.bindings Now if you put a commands dependency on bindings and a contexts dependency on commands. The ModelAssembler guarantees that (see ModelAssembler#topoSort): a) context fragments are loaded b) command fragments are loaded c) binding fragments are loaded Beside that if you use a ModelProcess you can rearrange the addons whenever you want - as the current fragment system doesn't allow you to contribute to any Application-Element you have to write a ModelProcessor. Tom -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindlgeschaeftsfuehrer/CEO eduard-bodem-gasse 5/1A-6020 innsbruck phone++43 512 935834 ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 using a mostly parallel structure to try and order the system. It's based on the assumption that your classpath dependencies will lead to the correct model. In the case where you have a plugin that defines the 20 things, and then separate implementation plugins, since inter-service dependencies are managed through the one plugin your order will once again be non-deterministic. This also doesn't solve the many-times stated problem in RCP land of being able to control the order of things in eclipse because we hide implemented the order in a hidden algorithm. Beside that if you use a ModelProcess you can rearrange the addons whenever you want - as the current fragment system doesn't allow you to contribute to any Application-Element you have to write a ModelProcessor. This depends on the last guy in being able to re-arrange a set of add-ons so that they're correct, which is another algorithm needed to be written in someplace else (and in a plugin that's gauranteed to be run last). I'm not 100% sold on my current method, but these will be problems with the assumption that each plugin can contribute it's information in the correct order. PW -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 working. Application addon contributionURI=platform:/plugin/p1/CommandServiceAddon / addon contributionURI=platform:/plugin/p1/CommandProcessingAddon / !-- Future -- addon contributionURI=platform:/plugin/p2/BindingServiceAddon / addon contributionURI=platform:/plugin/p2/BindingProcessingAddon / /Applicatio Current state: -- We require users to add 2 addon-elements in their Application.e4xmi and they have to be there in the exact order. If they don't things won't work at all 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 the generic case here our very specific one with the addons you mentioned in your first mail and here it is really simple to ensure this ordering, not? Tom Am 01.12.10 15:02, schrieb Paul Webster: On Wed, Dec 1, 2010 at 8:38 AM, Tom Schindl tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: 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 using a mostly parallel structure to try and order the system. It's based on the assumption that your classpath dependencies will lead to the correct model. In the case where you have a plugin that defines the 20 things, and then separate implementation plugins, since inter-service dependencies are managed through the one plugin your order will once again be non-deterministic. This also doesn't solve the many-times stated problem in RCP land of being able to control the order of things in eclipse because we hide implemented the order in a hidden algorithm. Beside that if you use a ModelProcess you can rearrange the addons whenever you want - as the current fragment system doesn't allow you to contribute to any Application-Element you have to write a ModelProcessor. This depends on the last guy in being able to re-arrange a set of add-ons so that they're correct, which is another algorithm needed to be written in someplace else (and in a plugin that's gauranteed to be run last). I'm not 100% sold on my current method, but these will be problems with the assumption that each plugin can contribute it's information in the correct order. PW -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindlgeschaeftsfuehrer/CEO eduard-bodem-gasse 5/1A-6020 innsbruck phone++43 512 935834 ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 the generic case here our very specific one with the addons you mentioned in your first mail and here it is really simple to ensure this ordering, not? I can solve it in any number of ways for my specific case, including setting up all 3 in the renderer. But these should represent the best practice for contributing modularized services in e4, since one of our 3.x complaints is that no one could work as well as the workbench services, since they were hooked up by hand using internals. If we have to do that, so be it, but I'd like to provide a best practice here :-) PW -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 none best practice. I'd even say that our url should not even have the bundle of the class but once we track back model elements back to their contributer we should use this bundle to load the class. Our current platform:/ uri system is IMHO not respecting bundle boundries which is a bad thing, which e.g. the extension registry would not allow because it uses the contributing bundle to load the class (Oleg correct me if I'm wrong here). Tom Am 01.12.10 15:59, schrieb Paul Webster: On Wed, Dec 1, 2010 at 9:55 AM, Tom Schindl tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: 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 the generic case here our very specific one with the addons you mentioned in your first mail and here it is really simple to ensure this ordering, not? I can solve it in any number of ways for my specific case, including setting up all 3 in the renderer. But these should represent the best practice for contributing modularized services in e4, since one of our 3.x complaints is that no one could work as well as the workbench services, since they were hooked up by hand using internals. If we have to do that, so be it, but I'd like to provide a best practice here :-) PW -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindlgeschaeftsfuehrer/CEO eduard-bodem-gasse 5/1A-6020 innsbruck phone++43 512 935834 ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 work. -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: 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 work. -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindlgeschaeftsfuehrer/CEO eduard-bodem-gasse 5/1A-6020 innsbruck phone++43 512 935834 ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 applied to (I think it's Lars or Tom that came up with this one but I like it...;-). That way somebody that wants the MinMax addon could simply declare it as a required plugin and immediately see the effect. Note that the MinMax addon in its current state could also have the 'Cleanup' addon as a required bundle. It would be better if the requirement wasn't quite that tight so we could allow folks to use the MinMax addon and supply their own Cleanup addon but then folks wanting the MinMax would have to 'know' that they also need something to manage stacks going empty... Can we do it this way Paul ? Eric From: Tom Schindl tom.schi...@bestsolution.at To: E4 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 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 tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: 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 work. -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindlgeschaeftsfuehrer/CEO eduard-bodem-gasse 5/1A-6020 innsbruck phone++43 512 935834 ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 MApplication-Element e.g.: addon:org.eclipse.e4.ui.workbench.addons.swt:DnDAddon addon:org.eclipse.e4.core.commands:CommandServiceAddon ... and only then contributes this addon. This way the one defines the Addon-Handler-Class is also the one who contributes the addon-element.https://dev.eclipse.org/mailman/listinfo/e4-dev The problem with extension points is they are read in an arbitrary order. Control of the ordering of this kind of thing has been a complaint on the RCP and/or Product side for a long time. If they go in the model, then document order controls them. But you're right, I traded e4.core.commands defined them and added them for you have to add these to your model, in the correct order. I'm open to suggestions or discussion on this. As an aside, this is part of the work that will get rid of the E4CommandProcessor. -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 ModelProcessor b) The model processor checks if there is a tag for the addon in the MApplication-Element e.g.: addon:org.eclipse.e4.ui.workbench.addons.swt:DnDAddon addon:org.eclipse.e4.core.commands:CommandServiceAddon ... and only then contributes this addon. This way the one defines the Addon-Handler-Class is also the one who contributes the addon-element.https://dev.eclipse.org/mailman/listinfo/e4-dev The problem with extension points is they are read in an arbitrary order. Control of the ordering of this kind of thing has been a complaint on the RCP and/or Product side for a long time. If they go in the model, then document order controls them. That's not completely true in the our ModelAssembler we do a sorting by evaluating the dependencies between the contributing bundles. So if e.g. keybindings has a dependency on commands e.g. then it is guaranteed by this algorithm that the commands contributions are processed before the keybindings ones! I think Oleg or Brian wrote the algorithm. Tom -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindlgeschaeftsfuehrer/CEO eduard-bodem-gasse 5/1A-6020 innsbruck phone++43 512 935834 ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 addons is that the bundle who contributes the Addon-Element to the model (e.g. contacts-bundle) is NOT the owner of the class (core.commands.service). I know that this is possible but I don't think it is good practice when we think into a more dynamic direction. e.g. the bundle contributing the addon-class is updated, uninstalled, ... we need to remove the addon and re-add it but if the addon-element owner is different to the addon-class we are probably getting into trouble. 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 MApplication-Element e.g.: addon:org.eclipse.e4.ui.workbench.addons.swt:DnDAddon addon:org.eclipse.e4.core.commands:CommandServiceAddon ... and only then contributes this addon. This way the one defines the Addon-Handler-Class is also the one who contributes the addon-element. Tom Am 23.11.10 14:36, schrieb Paul Webster: 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: 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=_LK0NgPZmEd-XstlTZ6nTXg elementId=org.eclipse.e4.ui.workbench.commands.model contributionURI=platform:/plugin/org.eclipse.e4.ui.workbench/org.eclipse.e4.ui.internal.workbench.addons.CommandProcessingAddon/ To run the compatibility layer against HEAD, you need to have the org.eclipse.platform project checked out into your workspace: dev.eclipse.org:/cvsroot/eclipse org.eclipse.platform R4_HEAD I'll be making the same changes to the context management and key binding management over the next little while as well. I'll post to the list when I release my changes with the implications (I can think of :-) [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=329646 Bug 329646 - Keybindings aren't found or shown when run from .jars -- Paul Webster Hi floor. Make me a sammich! - GIR ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindlgeschaeftsfuehrer/CEO eduard-bodem-gasse 5/1A-6020 innsbruck phone++43 512 935834 ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
Re: [e4-dev] Working with modeled UI and HEAD
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 to add an addon to the application. So any application including the workbench.swt.cocoa automagically benefit from the new menu definitions / adjustments. The downside is that these currently actions apply regardless of the widget binding used by the E4 application. It should likely be customized to only apply to applications using the SWT renderer. Brian. smime.p7s Description: S/MIME cryptographic signature ___ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev
