Bugzilla – Full Text Bug Listing
| Summary: | [prov] Enabling / disabling old update UI | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> |
| Component: | Incubator | Assignee: | Tim Mok <timothym> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | john.arthorne, pwebster, simon_kaegi, susan, timothym |
| Version: | 3.4 | ||
| Target Milestone: | 3.4 M6 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 219846 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
Pascal Rapicault
In case where update manager and p2 are both installed, we need an easy way to flip back and forth between the two UIs and even have them both enabled at the same time. Marking for M5 as per Monday's discussion. Created attachment 88333 [details]
Enable/Disable Old Update UI v01
This is my initial solution to enabling and disabling the old update UI. I've converted the Software Updates action set to a menu contribution with commands and handlers. The menu contribution has a visibleWhen with a property tester that checks the preferences. Due to property testers not being able to trigger an expression recalculation, I added the IWorkbenchPart check so that the expression is always up to date.
I think I have to put the code for this in org.eclipse.equinox.p2.ui.sdk?
TODO: The icons still have to be updated for the commands.
If the action set has to be kept (I don't see a reason to keep it), it'll be a bit trickier to hide the menu items but possible (I think).
Tim, I looked at the patch briefly and it seems like it's "backwards" from what we originally discussed, although this may not be an issue. In the patch, the p2 UI adds a dependency on the old update manager and defines commands/handlers there for the old stuff, using a pref for enabling the old UI. I didn't see any changes to ide to stop the contributions coming from there, or anything to hide the preference contributions of the old update manager. I was imagining that we would have the old update UI code look for p2, and if it's there, hide the old update UI contributions, unless there's a pref set to force it. I suppose this means that the pref to force it should always be available, even if the other preference contributions are hidden. The scenario I'm thinking of is that we want RCP apps to be able to build a p2-based story without dragging in any update manager stuff if they don't want to. And we might be configuring an SDK to run p2 only? I can remove the action set in org.eclipse.ui.ide for the old update manager and move in the menu contribution I added to org.eclipse.equinox.p2.ui.sdk. Does this remove p2's dependency on the old update manager? There should be a user option to the p2 preference and org.eclipse.ui.ide will read that preference to set the visibility of the old update manager UI. Then also add in a check for p2 and hide the old update UI depending on the user preference? What you describe sounds good to me, but I'm a bit confused myself on this. It seems we have a chicken/egg problem right now. In "the old days" (up to now), p2 knows update manager is there, and sets flags and such to control the old update's behavior. But moving toward actual integration, I'm not sure if we need to support an SDK configuration without p2 bundles being present. In other words, is p2 controlling the old UM behavior or are we moving toward the old UM looking for p2 and behaving accordingly? Or will the old UM assume that p2 is always there? Ideally, p2 would define the contributions, and the old UM would check the p2 pref. It would hide its contributions if the old UI wasn't supposed to be present. But if we need to support UM without p2, this won't work. Yet we want to be able to have a p2 UI without an update UI. I'm wondering...maybe we want to have some kind of p2<->UM UI bridge plug-in? This plug-in would require both, and it would check the pref and disable the UM contributions if necessary. Then our configurations would be: - UM only : use the old code - p2 only: use the p2 code. P2 defines the pref for old UI but doesn't do anything with it - UM + P2: add the plug-in which checks the pref and hides the UM contributions if the pref says the old UI is off. This is the best way I can think of, but it's best to double check with Pascal or John about configuration requirements... For 3.4, we need to support:
- Eclipse SDK containing UM only; p2 is completely absent ("UM only")
- Eclipse SDK containing UM and p2 ("UM+p2")
We don't need to support an Eclipse SDK with UM absent for this release. Likely in the next release we will flip over to supporting "UM+p2", or "p2 only". This means all dependencies on p2 for this release need to be optional, or of the flavour where you check for a property that may or may not be present.
I haven't looked at Tim's patch yet, but naively I would think we would have two preferences: one controlling visibility of old UI, and one controlling visibility of new UI. That way a system integrator or product builder could pick what they want and use a preference initializer to configure the product accordingly.
John says >We don't need to support an Eclipse SDK with UM absent for this release. True, but we don't want the p2 UI to be calling the UM UI (as in the patch). In other configurations (RCP) the p2 UI can be used independently. Tim, in my previous response I misread part of what you said: >I can remove the action set in org.eclipse.ui.ide for the old update manager >and move in the menu contribution I added to org.eclipse.equinox.p2.ui.sdk. Yes. That's right. That should do the trick. I think the only open question is how the prefs work. John, the "p2+UM" scenario is still fuzzy, at least to me. I understood we aren't trying to support a dynamic switch in underlying support, that is done at build time. The visibility preference is only needed for the p2 + UM case, where UM is invisible by default, and the user discovers they need it because of install handlers. If so, I don't think we need a visibility preference for the p2 UI. A product integrator simply won't include the p2 UI bundles if they don't want them. Another "p2+UM" question is whether making UM visible means making only "Find and Install" visible for the purpose of using install handlers, etc. or whether "Manager Configuration" is also shown (which will expose the old rollback, extension location UI, etc. etc.). Sorry if I'm making this more complicated than it should be. I'm just unclear on the usage scenario of the "p2+UM" case because at one time we said the intent was not to allow the user to flip back and forth. note from a discussion of this topic with Tim, John, Susan: in addition to making the switch work, we'll want some "back door" way for users to launch the update manager UI (indirectly by handler) so users can get to the old UI. Created attachment 88782 [details]
Enable/Disable Old Update UI v02
Moved the UM contributions to org.eclipse.update.ui. I've added the org.eclipse.equinox.p2.ui.sdk dependency for the plug-in and marked it as optional.
The preference contributed by org.eclipse.equinox.p2.ui.sdk is still there for testing.
*** Bug 217750 has been marked as a duplicate of this bug. *** Created attachment 89320 [details]
Enable/Disable Old Update UI v03
Patch changes:
+Used capabilities to hide the UM contributions.
The UM can still be called through a keybinding. The command-handler can be disabled but it wouldn't be able to be called from p2 when needed. The UM can be activated again by enabling the capability in the preferences. This can be removed later.
Created attachment 90390 [details]
Enable/Disable Old Update UI v04
Some minor updates on Tim's patch:
- Moved commands back to ui.ide plugin
- Handling of null shell in update handlers
- New activity pattern binding for update commands in ui.ide.
I have released Tim's changes in org.eclipse.equinox.p2.ui. I will open a separate bug against update to coordinate the changes on their side. Created attachment 90391 [details]
Subset of patch v04 for org.eclipse.ui.ide
Here is the portion of the above patch to be committed to org.eclipse.ui.ide. This needs to happen after the update ui change is in.
Update bug is 219846. Once that is released, we can release the remaining patch to org.eclipse.ui.ide, which switches from actionSets to command/handler mechanism. Created attachment 90680 [details]
org.eclipse.ui.ide changes moved to org.eclipse.ui.ide.application
The icons that need to be moved are not included in the patch.
(In reply to comment #17) > Created an attachment (id=90680) [details] > org.eclipse.ui.ide changes moved to org.eclipse.ui.ide.application Released to HEAD >20080225 PW Thanks all, marking fixed. |