| Summary: | The plugins settings page should clearly indicate the status of the plugin | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Michael Rennie <Michael_Rennie> | ||||||||||||
| Component: | Client | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | curtis.windatt.public, mamacdon, pwebster, simon_kaegi | ||||||||||||
| Version: | 6.0 | ||||||||||||||
| Target Milestone: | 7.0 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Mac OS X | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Michael Rennie
Not strictly related to the Settings page, but:
If one of the default plugins fails to load, you should get an error dialog no matter what page you're on. This means that basic functionality is not going to work, and the user needs to know. Something like this:
> Sorry! ${product} won't work correctly because some features couldn't be loaded:
> ✘ Orion JS Tools
> ✘ Orion File Service
>
> [↺ Try Again] [ Ignore]
Clicking Try Again would just refresh the failed plugins.
Created attachment 245309 [details]
Screenshot of new page
Created attachment 245310 [details]
UI Improvements
- Recognize the plug-in state, warn the user if plug-in is stopped, uninstalled or installed (not resolved).
- Sort the list by state then by alphabetical order
- Compact the entries, making the title the plug-in link, shrinking margins
- Fixing NLS for the page
Looks like there is some problem in the plug-in state code, as all of the running plug-ins stay as 'starting'. If I deliberately time out a plug-in or have a script error, the state also remains as 'starting'.
Created attachment 245355 [details]
Fix with checks for loading problems
Created attachment 245357 [details]
Updated screenshot
Simon, can you please sanity check the changes I made to pluginRegistry.js? When there is a problem updating a plug-in, a message is output to the console, but the plug-in object doesn't store that information in any way. It simply remains in the 'starting' state. I avoided changing the possible states in case they are be used as public API. We only recognize that a plug-in fails to load when it is activated. This means that a newly installed plug-in that is lazy loading will not be marked with any problems loading even if it returns no services. I think we can live with this, though something like what Mark suggested in comment #1 would help a lot with this case. I will make a small change to catch newly installed auto starting plug-ins. Thanks Mark for catching this case. Created attachment 245491 [details]
Fix v3
This fix adds a check for autostarting plug-ins when they are first installed.
Simon's on vacation, so I reviewed Curtis's changes to pluginregistry.js. I think they're fine, although getProblemStarting() should perhaps be renamed getProblemLoading() to match the docs and variable name. My only other question is whether we should eventually expose problemLoading() as different plugin states instead of a separate method. Hopefully Simon will have some input there. All the pluginregistry tests pass (once they are un-skip()'d). So +1 from me http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=50712b7b21f46e71c5a1ee276cb2493beef77ffd I changed the name to getProblemLoading. There is a disconnect between what we present in the UI and what we use in the pluginregistry. Registry v UI ------------- resolved v installed starting v enabled? (lazy loaded plug-in is ready to start) started v enabled stopped v disabled This is fixed for 7.0. We can have further discussion on usage of problemLoading() if we have more detailed information to provide to the user than 'something is wrong'. |