I've released the changes associated with this bug, so those of you running the admin and/or end user UI will notice differences in the way errors are handled, not just for automatic updating, but for any provisioning operation.
In the admin UI you will now get an install/update/uninstall wizard even if the computed provisioning plan was invalid. Old behavior was to get an error dialog. New behavior is you get the wizard with the error details reported there. In the end user UI, the handling of invalid plans is controlled by preference. The first time you try to provision something with a non-OK plan, you'll get a prompt as to whether you want to open the wizard anyway. If you say yes, you'll get the wizard. If you say no, you'll get the normal error dialog. In the automatic updater, if you have the preference set to prompt when a plan is bad or to always show the wizard, the updater will notify you when bad updates are found. The status bar icon will have the error overlay and the hover text tells you that it may not be compatible but that you can click to browse/review. If you have set your preference to "never open a wizard on a bad plan" then the updater won't bother telling you when updates don't compute a good plan. One nice thing for power users is that you can now select many versions of something, say "Install" and then check/uncheck boxes until you find one that works for you. Please read the bug for detail: https://bugs.eclipse.org/bugs/show_bug.cgi?id=217927 susan Susan Franklin McCourt/Beaverton/IB To: Equinox development mailing list <[email protected]> [EMAIL PROTECTED] cc: Equinox development mailing list <[email protected]>, Sent by: [EMAIL PROTECTED] equinox-dev-bounces@ Subject: Re: [equinox-dev] [prov] How best to help the user through incompatible/bad eclipse.org provisioning plans 02/13/2008 08:57 AM Please respond to Equinox development mailing list John said: > It would be nice if there as an unobtrusive way to let the user know though - such as a trim widget that gets an error overlay added. this is similar to the path I am exploring. To clarify - you'll never get told of an update if you don't have the pref on. The pref guides how often we check, whether we download before notifying, etc. But if you have the pref on, I was thinking of: - for updates with no problem - notify the user with the usual popup and status bar affordance - for updates with a failed plan - the status bar affordance has a red X, the popup is worded differently (the trick is the wording, a way to inform without scaring, and to make sure the user knows that clicking the popup just lets them browse the updates, nothing bad will happen automatically). Either case, clicking on the popup gets you the update dialog, and in the second case it has an error condition (bad as a general rule, but more informative than not telling them). Are you suggesting that you'd rather see the update icon/red X without the popup in the second case? Interesting.... For the manual checking for updates, install: Today we report the error if the plan fails. I was considering reporting the error with an option to "launch the wizard anyway" (and a toggle to remember the pref). Pascal said: >don't let the user click the install button until the proper things have >been selected. This means that the validation is done as the user selects >and unselects things in the UI. This is what we do once inside an update or install wizard (as you check and uncheck items, the plan is recomputed). But if what you mean is to compute the plan while making selections in the "available features page," I don't think that really helps. It is expensive, and noisy (you have to show progress somewhere). And if we just gray the update/install button, there is still all the same questions about how to show what's wrong. So my thinking is that the ability to launch the wizard anyway gives the user a place to try checking/unchecking things and recomputing the plan, rather than going back and starting over. And it keeps the basic workflow of browsing for what's available less cluttered by not doing full resolution all the time. susan Inactive hide details for John Arthorne <[EMAIL PROTECTED]>John Arthorne <[EMAIL PROTECTED]> John Arthorn To: Equinox development mailing e list <[email protected]> <John_A cc: rthorne Subject: Re: [equinox-dev] [prov] @ca.ibm How best to help the user through .com> incompatible/bad provisioning plans Sent by: equinox -dev-bo [EMAIL PROTECTED] clipse. org 02/13/2 008 07:39 AM Please respond to Equinox develop ment mailing list This is definitely a tricky problem. A likely scenario is that they have installed some additional plug-in, and that plug-in has a constraint that is not compatible with constraints in the updates (The extra plugin requires version 1 of "foo", and the update requires version 2). The problem is, our solver might not be able to come up with a simple explanation that makes any sense to the user (they likely know little about the various IUs they have installed). Until we can come up with an explanation that allows us to guide the user through correcting the problem, I would opt for keeping quiet in the automatic update case (just log it). Personally, it drives me crazy when applications have uninvited and unsuppressible modal popup dialogs about updates. If the update can proceed silently it's fine. If I explicitly asked for an update, it's ok to prompt me about problems. But if I didn't ask for it, don't bother me about it. It would be nice if there as an unobtrusive way to let the user know though - such as a trim widget that gets an error overlay added. In the updates dialog, we would presumably still show the updates, and the user can try the update from there if they want to. John Susan Franklin McCourt <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] To org [email protected] cc 02/12/2008 05:33 PM Subject [equinox-dev] [prov] How best to help the user through incompatible/bad provisioning plans Please respond to Equinox development mailing list <[email protected]> Hi, everyone. I've been struggling with how to handle the case where the user has automatic updates on, we find updates, but the resulting provisioning plan for those updates is not OK. Meaning, there is some incompatibility/problem. Do we tell the user? Do we let them try to update anyway? etc. etc... This issue also applies to provisioning actions the user selects. They select A, B, C and say "Install..." but the resolver can't find a plan that satisfies everything. What then? We currently just report the (often cryptic) error. Should we let them try anyway, or at least open the wizard and let them check/uncheck things until they get a good solution? If you have any thoughts in this area, could you please read and respond in this bug? https://bugs.eclipse.org/bugs/show_bug.cgi?id=217927 thanks, susan_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
<<inline: pic07849.gif>>
<<inline: 26184439.gif>>
<<inline: 26896516.gif>>
<<inline: 26352088.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
