Community
Participate
Working Groups
If you have a view open on shutdown that is subsequently removed (via update manager or because the workspace was opened with a different Eclipse instance) you are greeted with an error dialog on startup saying that the workbench layout cannot be restored. While it is indeed worth noting this condition, treating it as a severe error is, I feel, too extreme. Merely switching between Eclipse instances shouldn't invoke this kind of response. Simply logging the message as a warning or error should be sufficient. Other alternatives: provide a "dont show me again" box in this error dialog that looks to a preference that can be overridden by plugin_customization.ini move IDEStatusHandler to API so that products could choose to ignore the error or handle it differently
Created attachment 89186 [details] Patch allowing clients to set the WB's StatusManager style for restore failures We should mark this as "Here be Dragons" (i.e. use with care) since it changes the response 'globally', not just for the particular case of a view not being able to be found...).
I'm looking at the Dialog stuff now...
I'm still thinking about this, I'm not comfortable with the current solution (it's too coarse). There might be an interesting twist on the new preference though. The update manager could set it to LOG for the -first- restart after an update (where changes might reasonably be expected) and then revert to SHOW. Kim, if we did this would we have to make the preference API or could we keep it internal ?
I've just changed the header to reflect that this defect should examine all cases where we get 'unexpected' results from a startup. Our current handling is too intrusive when plug-ins are unloaded/removed between starts (i.e. showing a dialog when a view can't be re-created because it isn't -defined- any more). The basic approach seems clear: 1) Ensure that all the reporting is done through the StatusManager. 2) Clean up the generated exceptions to have more meaningful 'codes', allowing sub-classed StatusManagers enough context to do something meaningful. Once that's done we can tweak our own StatusManager to LOG rather than SHOW exceptions (using the new codes?). Also, there's an apparent conflict in the desired behavior even within our useage: One scenario has an 'update' being performed by the user to remove some 'feature'. Here the user expects that views should go away 'silently'... The other scenario if someone getting a new eclipse install and opening it against an old WS containing visible views from GEF. In this case the 'error part' would be better since they subsequently want to use the Update Manager to re-install the neceessary feature and want the view to re-appear once the feature is available.
For my money I think that the second scenario is somewhat less important since it's a workflow that isn't really common in our user community. The issue only occurs when opening a WS that was originally targeted at a GEF-enabled install is opened. If the user had a 'vanilla' WS (called 'cleanInstall' or somesuch) they could open that after a re-install, update/re-add the desired features and then open the real WS after everything is installed. This way no view/editor info would be lost.
Created attachment 102030 [details] Simpler patch that uses the StatusManager to LOG the event rather than SHOW'ing it...
Note that if you were trying to restore an editor for which there is no longer a handler you get different restults; You get what appears to be a non-modal dialog telling you that there's a problem followed by a perspective -reset- !!
Kim, can you review the patch for me ?
Paul, could you be eyes #2?
Are those strings that are no longer being used referenced anywhere else? Could we remove those? Anyhoo, +1.
McQ, I think that this is still worth doing even though we can't solve the DetachedWindow case (i.e. you get a 'permanent' empty DW if it only contained a view that can no longer be created). The current code has this issue, it's not induced by the fix (we're simply using LOG instead of SHOW for the response type). The fix does however cover the non-detached cases...
+1 for Eric's simpler patch. Need new bugs to track the clean up of the messages and to fix the floating window issue post 3.4
Committed in >20080528. Applied the patch. The other defects have been created (bug 234280 for the messages and bug 234484 for the 'empty' DW's).
Ooops, bug 234480 for the messages...
Verified in I20080528-2000.
Re-open for a deeper fix...
Moving to 3.5. The fix for this will require more analysis.
*** Bug 245789 has been marked as a duplicate of this bug. ***
Moving to triage (for now), we should re-target this work for 3.6 when it becomes available...
*** Bug 233617 has been marked as a duplicate of this bug. ***
*** Bug 237727 has been marked as a duplicate of this bug. ***
*** Bug 240453 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
