> Stefan: How does it happen right now? Are most dialogs modal "by default"? If so, could we simply have a preference in Platform UI to set the default behavior and
> that we could switch to try it out, and once we're all convinced it's working, to enable it in delivery?
If we're just talking about disabling the modal flag, you'd just need to search for and delete all occurrences of the SWT.*_MODAL flags. That's the easy first step.
There's some code in the JFace window class that reparents Shells to prevent deadlocks among modal dialogs. I've recently become aware of some code in P2 that was intentionally creating deadlock scenarios in order to trigger that reparenting, it was relying on that as its primary strategy for parenting Shells. I don't know how widespread this antipattern is, but we'd have to test for incorrectly-parented dialogs after flipping the flag. If I recall, this antipattern was a workaround for the fact that some of the utility methods for computing the active shell were incorrectly returning null in a lot of circumstances on GTK. We'd have to fix those bugs in order to parent the nonmodal shells properly... but I don't think it's very hard and I can dig up the original bugs if anyone is serious about wanting to do this.
At this point, you'd have a stable change we could probably use. I don't think you'd need to bother with a preference since it's unlikely to cause any serious problems (if a nonmodal Shell does get incorrectly parented, it's easier for the user to just find it and click on it than it is for them to disable a preference and reopen the Shell).
If someone wants to do that, I'd help review the patch.
However, just flipping the modal flag won't really address the more serious UX issues caused by the presence of dialog boxes. If I were to write my own patch here I'd be inclined to spend my time replacing the dialogs rather than simply making them nonmodal.
Â - Stefan