[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ui-best-practices-working-group] Modal dialogs

> 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

On Tue, Sep 20, 2016 at 7:36 AM Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:
As Stefan mentioned, it is not just a simple switch. First, a good/better UI has to be provided (also already mentioned by Stefan) and second, all the new cases that can now happen because the UI is no longer locked, need be handled by the code, e.g. files changed or deleted by the user before the user takes action on the message - lots of work!

Dani



From: Â Â Â ÂMickael Istria <mistria@xxxxxxxxxx>
To: Â Â Â Âui-best-practices-working-group@xxxxxxxxxxx
Date: Â Â Â Â16.09.2016 07:41
Subject: Â Â Â ÂRe: [ui-best-practices-working-group] Modal dialogs
Sent by: Â Â Â Âui-best-practices-working-group-bounces@xxxxxxxxxxx




@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?
--
Mickael Istria
Eclipse developer for
Red Hat Developers
My blog - My Tweets_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group

_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group