Community
Participate
Working Groups
As M6 is the API freeze I think we need to decide if some changes are required here 1) It is not a dialog it is something that manages the opening of a dialog. It needs to be renamed. 2) Test mode just means "run in sync exec". I am not sure why we even want this as an asyncExec and a syncExec is a no-op on the UI Thread. 3) Is it the intention of this class to just provide an API way to invoke an internal dialog? The dialog itself can't be modified as InternalDialog is where all of the work is done.
*** Bug 222947 has been marked as a duplicate of this bug. ***
StatusDialog is not subclassable therefore still open for extending. In the future I am planning to open it for subclassing and make it extending TrayDialog(as far as I know it will be binary compatible). After those changes user will see WSD as a normal dialog, which has the ability to adjust the modality state change in a pretty gentle way :). This is not done for 3.4 because subclassable WorkbenchStatusDialog will be a really heavy task :(. I do believe I am able to defend API regarding points 1 & 3. Point 2 I will check, I hope today.
Ok so let me see if I understand. This is meant to be a dialog someday but isn't for now?
basically yes
So why did you approach it this way? Changing the superclass will break source compatibility and will affect the constructors at least significantly.
(In reply to comment #0) > 1) It is not a dialog it is something that manages the opening of a dialog. It > needs to be renamed. > 3) Is it the intention of this class to just provide an API way to invoke an > internal dialog? The dialog itself can't be modified as InternalDialog is where > all of the work is done. We removed the inheritance because it could be error-prone, if we wanted to open WSD for subclassing. The internal dialog uses/will use the outer dialog methods to create its contents. So when WSD is open for subclassing, we would extend internal dialog by extending the WSD. (In reply to comment #3) > Ok so let me see if I understand. This is meant to be a dialog someday but > isn't for now? > (In reply to comment #4) > basically yes I don't agree. This class in not a real dialog on purpose and I would not change it in the future. We can even change its name to WorkbenchDialogController, StatusDialogController or something similar. (In reply to comment #2) > StatusDialog is not subclassable therefore still open for extending. In the > future I am planning to open it for subclassing and make it extending > TrayDialog(as far as I know it will be binary compatible). In my opinion it is not necessary to make the WSD a TrayDialog subclass.
As the M6 warm up build is today we couldn't wait any longer. I renamed the WorkbenchStatusDialog to WorkbenchStatusDialogManager and tidied up the other issues.
Verified in I20080325-0100
