Good question !! The short answer is 'not really'....<no smiley> Should we have both a simple / naive approach (a la DirectMenuItem vs Commands/Handlers/KeyBindings) as well as a more robust one for more sophisticated (enterprise?) RCP apps ?
In it's simplest form this might be to add a 'docURI' field (in MUIElement? MContribution?) and write a view that tracks the active part and extracts the 'docURI' and displays it. In this case we should also look at: - The 'Intro' handling (the Welcome view that comes up on a fresh install) - How about 'Cheat Sheets'? A more general observation: As we go through the maturing process we are likely to find that eclipse 3.x has quite a few areas in which it has a *very* mature set of capabilities. Many of these come with complete extension infrastructures, including specialized extension points and views, wizards and commands that understand the extensions. Trying to re-implement this would be re-inventing the wheel IMO, I'd prefer to see if we can make it possible to make the compatibility layer light-weight enough to use even in E4 apps In order to do this we'd have to invert the way that the compatibility layer currently works so that when a legacy part is referenced the necessary wrappers are created (Workbench, WorkbenchWindow/Page). If we can get to this point an RCP app could, for example, re-use the PackageExplorer (or Dynamic Help) in their app just by adding the Compatibility bundle(s). While at the start we'd expect this to be fairly expensive I suspect that we can reduce the overhead quite a bit. I'm currently working towards this goal for the 4.1 SDK code so that it can be started using the standard E4Application's mechanisms (right now we use the legacy code in Workbench#runUI for example rather than having the Workbench simply 'appear' on the first call to PlatformUI.getWorkbench...). If we can get to this point then the re-use in an RCP app should be trivial. Then we should look at 'lazy loading' *everything* we can so that only when a particular capability is required would we instantiate it. So if the legacy component you're using doesn't need ISharedImages then they won't be loaded at all. Over the next few release cycles we can see if we can get various other components (JDT, Debug...) to re-arrange their bundles and requirements to even further optimize for particular re-use scenarios but that would be after 4.1 goes out (and we can identify which specific 3.x bits we would like to be 'native' in E4 apps). In true IBM fashion you could consider this the 'on demand' IDE...;-). Eric From: Lars Vogel <[email protected]> To: E4 Project developer mailing list <[email protected]> Date: 11/30/2010 04:14 PM Subject: [e4-dev] Help story for e4 Sent by: [email protected] Hello, Do we have a help story for e4 without the compatibility layer? AFAIK the commands "org.eclipse.ui.help.displayHelp", "org.eclipse.ui.help.helpSearch" and "org.eclipse.ui.help.dynamicHelp" cannot be re-used in a pure e4 environment. Best regards, Lars _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
