Bugzilla – Full Text Bug Listing
| Summary: | [Intro] Display welcome info for a newly installed/updated feature | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jin Li <jinli> |
| Component: | User Assistance | Assignee: | platform-ua-inbox <platform-ua-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | birsan, dejan, eclipse, jeffmcaffer, warrend |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Jin Li
Mazen, is there anything you need from update? This is a problem we didn't solve in 3.0 - since feature contribute into the unified intro, it is hard to highlight these new contributions. Perhaps we need to automatically generate a page on the fly composed of all the new contributions (new links/elements/text) i.e. show only the delta. Adding Jeff because we need the handshake with the runtime. We need to have a mechanism whereby agents (extensions?) register their interest in being notified when the configuration changes. These agents can be: 1) Intro - to show the delta of the intro content when new features are installed 2) Platform UI - to highlight new UI artifacts contributed by the new features 3) Help - to hightlight new topics/books contributed by the new features It would be easy to define the extension point in update but that would leave RCP outside. Hence a cc to consider an alternative notification on a bundle/bundle group level. Note that this handshake existed prior to 3.0 (thanks to it, we used to open Welcome pages for new primary features when installed). since the runtime does not know about features, the best we can do is tell people about plugins being installed. This is already supported by registering a BundleListener. The only drawback of this approach is that it is not declarative. Is this a problem? Listening to bundles being added/removed is not enough. What is needed is the information about changes between two invocations. The scenario is: 1) The user installs new feature 2) The user restarts the workbench 3) Upon startup, the intro opens showing the new contribution to intro for the new feature The problem here is that without declerative registration, clients like intro will not be loaded to process changes. In addition, we are talking about the delta that resulted on the actions in the previous session. Configurators are in unique position to provide this information because they compute bundles to pass to the framework on each startup i.e. they can easily figure out the delta. The challenge is to allow configurators to report this delta somehow and to do it to the list of delta listeners registers decleratively. Note: Configurators are not part of the runtime. They are a logical entity that *typically* runs early on in the Eclipse startup sequence. Some configurators may even run before the runtime (e.g., ones integrated into the OSGi framework). Configurators decide what plugins to present to the runtime but the runtime does not necessarily accept all such plugins. For example, plugins which do not resolved play no part in a running Eclipse. Even though the configurator has successfully called installBundle(), no part of Eclipse should be considering unresolved bundles. Note also that there may be several configurators all of which may have different behaviour. You likely do not want to tie the fortunes of Intro to random collections of configurators that may or may not broadcast such events. The resolver (via bundle events) broadcasts changes to the set of bundles which are resolved in the system. Changes in the state are captured in a state timestamp. This is a very coarse grained value meant for use in invalidating caches (e.g., the registry itself). One approach would be to have Intro remember the set of bundles that have intro info as well as the state stamp. If on startup the state stamp is different from last time, something has changed and Intro should reconsider its "cache" of intro bundles. Newly installed/resolved intro bundles are then discovered and stale ones discarded. Jeff, the problem is that we don't want intro plug-in to run on startup every time in order to perform the required delta computation. Intro is shown by the workbench UI in certain situations but once closed, it will not run until explicitly opened by the user from 'Help>Welcome'. The issue here is one of bootstrap - we want intro to be prompted to perform delta computation and show the delta content only when there is delta to be computed. Consequently, some part of the stack needs to invoke intro or provide initial kick when new bundles have been installed. I keep going back to declerative registration because it is the only one allowing proper bootstrap of interested listeners on startup (i.e. a bundle must be active in order to add itself as a listener programmatically; declerative registration solves this 'catch 22' problem). The declarative approach has problems in my mind. The best we will be able to do is allow people to register extensions to a runtime extension point such that when any (and every) bundle changes from installed to resovled or resolved to installed we fire a generic event saying "something changed". In many cases we would be able to say which bundle changed but not all the time (there will be times that things are (un)installed before the runtime is operational). So, for example, on first startup you will get kicked 1500 times in some well known product scenarios. A side issue in that particular case is that their first run is at install time and is headless with -initialize (or some equivalent). This run installs all the bundles and so your attempts to do intro things on install may be foiled (no UI is started). On subsequent runs nothing changes. A more subtle problem is that Intro should not really be incharge of when it shows up. In some scenarios the policy you outlined is great, in others less so. Perhaps the approach should be to have the application (advisor or some such) decide when to kick Intro? Not that it helps you but this is part of a more general problem of declaratively registering listeners. For example, what if you only want to do sometihng if people are changing resources? Currently your only option is to start() and register a resource change listener or to be a builder. Neither is very friendly. Adding Rafael the registry man to see if he sees something here that I am missing. The fix for Bug 177635 sounds like what you are looking for. *** This bug has been marked as a duplicate of bug 177635 *** |