Community
Participate
Working Groups
In 3.1 a new constructor was added to Window - Window(IShellProvider shellProvider). It was also added to Dialog. Constructors were not added to the public subclass ProgressMonitorDialog so now our private ProgressMonitorDialogs cannot take advantage of this. We want to add ProgressMonitorDialog(IShellProvider) to the API. It will call the API in the super class and otherwise work like ProgressMonitorDialog(Shell).
The problem is much more widespead than just ProgressMonitorDialog. There are numerous other existing Window and Dialog subclasses that could benefit from the new mechanism for computing the parent shell. However, adding a new constructor to each of these classes is a painful solution. Here's a sketch of a small rework of the shell provider mechanism that would be inherited automatically by all subclasses: Define on Window /** * Sets the parent shell provider for this window. The shell provider * supplies the parent shell when the window's shell is created by * <code>create()</code>. If a parent shell provider is supplied, it * overrides the shell specified on the constructor. * * @param shellProvider the shell provider; must not be <code>null</code> */ public final void setParentShellProvider(IShellProvider shellProvider); Remove new constructors (likely no longer needed) public Window(IShellProvider shellProvider); public Dialog(IShellProvider shellProvider); public TableSortDialog(IShellProvider parentShell, TableSorter sorter); Example usage: Window w = new ProgressMonitorDialog(anyOldShell); w.setParentShellProvider(myShellProvider); w.create(); (Also, I believe there's a bug in the getParentShell() method, which will NPE if the old constructor is used to create the window.)
(Doh! setParentShellProvider above should also include @since 3.1)
Tod and I discussed having a setParentShellProvider method, but preferred the constructor for the following reasons: - Not all dialogs can support having their parent shell changed without notice, so updating each dialog means that only dialogs that support the new mechanism will have it as API. (Even setParentShell is currently protected, so dialogs that don't support reparenting aren't forced into offering it as public API.) - Since setParentShellProvider is intended to be called by the code that creates the window, it has access to the concrete class and doesn't need to access setParentShellProvider via a pointer to the Window base class. Without this requirement, it is better to give each dialog the power to decide on its public API rather than forcing it through the base class. If the dialog wants to support a setParentShellProvider method, it could still do so by implementing an IShellProvider that dynamically delegates to whatever was given to setParent*, and passing the delegating implementation up to the base class. - setParentShellProvider may require less code to implement, but it would still require the same magnitude of tedium (since someone needs to call the method). - Having a constructor argument that is immediately ignored is inelegant. - Objects are easier to use if you can fully initialize them with their constructor. I am not strongly tied to this one way or the other and will happily go along with the majority if nobody else finds these arguments convincing.
BTW I have also been working on Bug 89900 and it turns out this API will not make any difference anyways (I am not going to need an API change for it). I suggest we defer this post 3.1. If it is OK with everyone I will withdraw my API request.
What is the consensus on this? We mayneed to do it now to solve Bug 95048 which may become more acute with propsed SWT changes.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
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. If you have further information on the current state of the bug, please add it. 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.
I recently encountered that TitleAreaDialog is missing IShellProvider constructor also And even though (In reply to Jim des Rivieres from comment #1) > adding a new constructor to each of these classes is a painful Maybe it is better than waiting another 15 years for the perfect solution? :-)
