Community
Participate
Working Groups
Build Identifier: MApplication addons are model to post processors. However, no mechanism exists to allow the addons to be run in a specific order. Adding an "order" property, such as an int, would allow sorting to be applied to the list. Unordered addons would run first in any order, then sorted addons would run. This is very similar to a BeanPostProcessor.order property in the springframework. The use case is where you want to try and run an addon to manipulate windows so that it can modify the visibility of a window with a specific tag, such as a logon window and you want to set all other windows to non-visible. In this case, you have to ensure that you run last so that you can run on the entire window list and ensure any other window processing addon has completed its work. Reproducible: Always
What should happen of two add-ons declare themselves as the "last" add-on?
I currently prefer that the model specifies them in document order. PW
(In reply to comment #2) > I currently prefer that the model specifies them in document order. What's document order? Instead of an integer (or floating point), we could specify "before" and "after". We currently topologically sort model fragments based on bundle dependency. This code is easily pulled out (org.eclipse.e4.ui.workbench/src/org/eclipse/e4/ui/internal/workbench/ModelAssembler.java #topoSort)
(In reply to comment #3) > (In reply to comment #2) > > I currently prefer that the model specifies them in document order. > > What's document order? technically, model order (I see too much xmi :-) > Instead of an integer (or floating point), we could specify "before" and > "after". we have at least 5 different extension point "sorting" schemes in 3.x. They all work for 80% cases and fail miserably for the last 20%. If you have an open-ended contribution system, you will always get "well, it's OK *most* of the time" situation. By controlling the execution by the model child order, we guarantee that we'll execute something that is application visible. If some enterprising application wanted to swap the model element order around, they would have the fine grained control they've always been after. If not, our fragment contribution system will give them something similar to the "almost good enough" system they have available now. PW
(In reply to comment #4) > By controlling the execution by the model child order, we guarantee that we'll > execute something that is application visible. If some enterprising > application wanted to swap the model element order around, they would have the > fine grained control they've always been after. If not, our fragment > contribution system will give them something similar to the "almost good > enough" system they have available now. That sounds like WONTFIX
(In reply to comment #5) > > That sounds like WONTFIX I think we still need to discuss it some more. But as you can tell from comment #4 my personal opinion is that we should avoid going down the same road again :-) PW
(In reply to comment #6) > I think we still need to discuss it some more. But as you can tell from > comment #4 my personal opinion is that we should avoid going down the same road > again :-) I'm inclined to agree. Since addons exist for the lifetime of the UI, they can manipulate the UI through the model as and whenever they like so that there's no real "last addon". These addons need to use the event broker to monitor and respond to changes to the UI model. The only reason I can see for wanting ordering is to ensure that particular services have been set up (e.g., the commands service or key bindings service), but we can get that through the OSGi require-bundles dependency used for handling fragments. In response to comment #1, you might want to look at the Cocoa UI Handler (org.eclipse.e4.ui.workbench.renderers.swt.cocoa, specifically CocoaUIHandler#hookWorkbenchListeners()), where it tracks events for new-window-realized to install and drop additional window handlers.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
