Details
-
Type:
Feature Request
-
Status: Closed (View Workflow)
-
Priority:
Critical
-
Resolution: Done
-
Affects Version/s: 3.3.0.M3
-
Fix Version/s: 3.3.0.M5
-
Component/s: runtime-detection, usage
-
Labels:None
Description
Request to let usage reporting modal dialog is opened first and then it is covered by bigger Runtime Detection Dilaog. Usage dialog is modal and nothing can be pressed and changed in Runtime Detection dialog. Sometimes I even didn't notice usage dialog and it was confusing because runtime detection dialog just didn't respond to mouse events.
There should be a way to show such dialogs one by one and not all at once blocking each other.
Gliffy Diagrams
Issue Links
- cloned from
-
JBDS-1795
Runtime Detection Dialog during first start gets over modal dialog with request to let usage reporting.
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
guess that this is a fine path to solve the problem with our own runtime detection dialog. But the problem would still persist with 3rd party dialogs.
Andre Dietisheim
added a comment - guess that this is a fine path to solve the problem with our own runtime detection dialog. But the problem would still persist with 3rd party dialogs. Shell#forceActive seems not to work on Linux/GTK according to this eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=244597
Andre Dietisheim
added a comment - Shell#forceActive seems not to work on Linux/GTK according to this eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=244597 Shell#force obviously does not work on Mac either: https://issues.jboss.org/browse/JBDS-1795?focusedCommentId=12629633&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12629633
Andre Dietisheim
added a comment - Shell#force obviously does not work on Mac either: https://issues.jboss.org/browse/JBDS-1795?focusedCommentId=12629633&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12629633 we ran out of time for this issue since we had a high rush towards JBIDE-9793. Moving it to Beta1
Andre Dietisheim
added a comment - we ran out of time for this issue since we had a high rush towards JBIDE-9793 . Moving it to Beta1 Could we find a better way to get Runtime detection to show up ?
i.e. its own editor/view or a nonmodal notification ?
Max Rydahl Andersen
added a comment - Could we find a better way to get Runtime detection to show up ?
i.e. its own editor/view or a nonmodal notification ? I have fixed the issue using the active shell instead of the Eclipse workbench shell.
Both dialogs are still modal. If the usage dialog is created before, the runtime dialog will use the shell of the usage dialog as a parent and won't be blocked.
If the usage dialog is created after creating the runtime dialog, the usage dialog will use the shell of the runtime dialog as a parent and won't be blocked.
I have added the SWT.APPLICATION_MODAL flag to the runtime dialog to suppress closing the runtime dialog when closing the usage dialog.
This fix is similar to the fix for JBIDE-9953.
I have tested the issue on Windows and Linux.
Snjezana Peco
added a comment - I have fixed the issue using the active shell instead of the Eclipse workbench shell.
Both dialogs are still modal. If the usage dialog is created before, the runtime dialog will use the shell of the usage dialog as a parent and won't be blocked.
If the usage dialog is created after creating the runtime dialog, the usage dialog will use the shell of the runtime dialog as a parent and won't be blocked.
I have added the SWT.APPLICATION_MODAL flag to the runtime dialog to suppress closing the runtime dialog when closing the usage dialog.
This fix is similar to the fix for JBIDE-9953 .
I have tested the issue on Windows and Linux. Verified in JBossTools 3.3.0.M5 H53
Radim Hopp
added a comment - Verified in JBossTools 3.3.0.M5 H53 
One way is to find an alternative way for runtime detection results to show up. maybe have it open a view or editor instead ?