| Summary: | PopupMenu does not insert a new element when touchdisplay is enabled | ||
|---|---|---|---|
| Product: | [Modeling] GMF-Runtime | Reporter: | Andreas Muelder <Andreas.Muelder> |
| Component: | General | Assignee: | Andreas Muelder <Andreas.Muelder> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Andreas.Muelder, give.a.damus, martin.axelsson1, pierre-charles.david, ralphgerbig, selic, sleicht, Vikas.Chandra |
| Version: | unspecified | ||
| Target Milestone: | 1.11.0 | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 512946, 514431 | ||
|
Description
Andreas Muelder
Can you please merge this for Mars.2 ? Hi, same here. I applied the fix from Andreas and it worked. If you want to have the fix provided via Gerrit and Andreas does not find time to do so, I could provide it. Best Regards, Ralph Hi, I have the same problem on my Lenovo Yoga 2 Best regards Stefan Hi, I wonder if there are any plans to implement this (in Neon?). We have a customer pushing to get this fixed. Thanks Martin I dont have windows 10 machine. But based on bug 480318 and discussion with SWT committers, this is the correct thing to do. Added comment and pushed to masters via http://git.eclipse.org/c/gmf-runtime/org.eclipse.gmf-runtime.git/commit/?id=571784ba0470e9bcccbf45d2c636705e686aef63 (In reply to Vikas Chandra from comment #6) > I dont have windows 10 machine. But based on bug 480318 and discussion with > SWT committers, this is the correct thing to do. > > Added comment and pushed to masters via > > http://git.eclipse.org/c/gmf-runtime/org.eclipse.gmf-runtime.git/commit/ > ?id=571784ba0470e9bcccbf45d2c636705e686aef63 Vikas, I saw you set the "Target Milestone" to 3.0. I would have expected 1.11.0 as this is the upcoming version of GMF Runtime for Oxygen, but maybe these aspects of the project were handled differently from what I'm used to. What does "3.0" correspond to? Pierre-Charles, I intended to put this fix from Andreas to Oxygen as well as Neon releases. I have pushed this to master ( I expect this to correspond to Oxygen). Based on http://www.eclipse.org/modeling/gmp/development/releases.php 1.11 should be oxygen and 1.10 should be neon. (In reply to Vikas Chandra from comment #8) > Pierre-Charles, > > I intended to put this fix from Andreas to Oxygen as well as Neon releases. > > I have pushed this to master ( I expect this to correspond to Oxygen). > > Based on http://www.eclipse.org/modeling/gmp/development/releases.php > > 1.11 should be oxygen > and 1.10 should be neon. That's right, but master has already been bumped to 1.11.0 by Anthony a few months ago (see commits 20066d9dce4bc3d7aaeb7e4a4a85b494e4c64ac9 and cb0f7f08b4e264d70844e4e41138e78fc6d42e11). If we want a fix for Neon.3, we'd need to apply the fix on branch R1_10_maintenance and prepare a 1.10.1 maintenance release for Neon.3. I've cherry-picked the fix on branch R1_10_maintenance, and created a new job to build the maintenance release at https://hudson.eclipse.org/gmf-runtime/job/gmf-runtime-1.10.x/ For now the new job does not publish the result. I am not yet fully up-to-date wrt how releng was done by Anthony's scripts and I don't want to risk breaking things. Neon.3 RC1 is in 3 weeks, so this should leave enough time to handle the remaining tasks (bump, build & publication, contribution to the SimRel). The build result with the patch included is available at https://hudson.eclipse.org/gmf-runtime/job/gmf-runtime-1.10.x/2/artifact/update-site/. It's a temporary location and still numbered 1.10.0 until I make the version bump and publish it at a proper location, but if people who experienced the issue can test it and confirm it's fixed in the meantime, feedback is welcome (I don't have access to a Windows 10 machine either). (In reply to Pierre-Charles David from comment #10) > The build result with the patch included is available at > https://hudson.eclipse.org/gmf-runtime/job/gmf-runtime-1.10.x/2/artifact/ > update-site/. This fix doesn't seem to be included in any GMF release as of the Neon.3 release. What is its current status? Papyrus-RT is using this PopupMenu API, and it is currently not working for users of our 0.9 release when they have touch enabled. (In reply to Christian W. Damus from comment #11) > (In reply to Pierre-Charles David from comment #10) > > The build result with the patch included is available at > > https://hudson.eclipse.org/gmf-runtime/job/gmf-runtime-1.10.x/2/artifact/ > > update-site/. > > This fix doesn't seem to be included in any GMF release as of the Neon.3 > release. What is its current status? > > Papyrus-RT is using this PopupMenu API, and it is currently not working for > users of our 0.9 release when they have touch enabled. GMF Runtime 1.10.1 has not been included in Neon.3, see my comments on https://bugs.eclipse.org/bugs/show_bug.cgi?id=512946#c4 for why. Actually, I planned to release 1.10.1 right after, but... other stuff happened and I let that slip, sorry. I launched an 'R' build this morning, which is available at http://download.eclipse.org/modeling/gmp/gmf-runtime/updates/releases/R201703310734. It's the final bits for 1.10.1, now tagged as R1_10_1. (In reply to Pierre-Charles David from comment #12) > > GMF Runtime 1.10.1 has not been included in Neon.3, see my comments on > https://bugs.eclipse.org/bugs/show_bug.cgi?id=512946#c4 for why. Thanks, Pierre-Charles! Much appreciated. It matters not to Papyrus-RT that the fix is post Neon.3; with our Oomph-based distribution we can easily deliver it to our users. I hope to be able to report back next week about verification of the fix on a Windows 10 laptop (of course, I can't test it in my virtualization environment). (In reply to Christian W. Damus from comment #13) Indeed, my Windows 10 user reports that this does not fix the problem of selections in the PopupMenus created by Papyrus-RT failing to trigger any actions. It seems that the selection event is still not sent to any menu-item widgets. Should we re-open this bug? Do we have any other reports from testing this fix? (In reply to Christian W. Damus from comment #14) > (In reply to Christian W. Damus from comment #13) > > Indeed, my Windows 10 user reports that this does not fix the problem of > selections in the PopupMenus created by Papyrus-RT failing to trigger any > actions. It seems that the selection event is still not sent to any > menu-item widgets. > > Should we re-open this bug? Done. > Do we have any other reports from testing this fix? Not that I know of. Several commenters mentioned they were impacted by the bug, but I got no feedback on the fix, except Ralph who mentioned the original patch fixed the issue for him. I can not test it myself (I don't have neither a Windows 10 machine nor a touch-screen). @Andreas, @Ralph: Apparently the initial patch worked for you. Can you test on an official build (http://download.eclipse.org/modeling/gmp/gmf-runtime/updates/releases/R201703310734) to make sure the fix was correctly applied and included in the build? @Stefan, @Martin: can you check if the build at http://download.eclipse.org/modeling/gmp/gmf-runtime/updates/releases/R201703310734 fixes the issue for you? I hope the bug (and fix) is not specific to some specific combinations of Hardware/OS/version of SWT... @Pierre-Charles I tested the latest build with my product and it worked for me. (In reply to Andreas Muelder from comment #16) > @Pierre-Charles I tested the latest build with my product and it worked for > me. Thanks for the feedback. So apparently the patch is fine and correctly applied, but may not solve the issue completely/in all contexts. Which version of Java/Eclipse/SWT are you running on? I am running on a Windows 10 with Eclipse Neon.2 and Java 8. @Christian Which setup does not work for you so I can try to reproduce this on my machine? (In reply to Andreas Muelder from comment #18) > I am running on a Windows 10 with Eclipse Neon.2 and Java 8. > > @Christian Which setup does not work for you so I can try to reproduce this > on my machine? That's the difficulty: I do not have the hardware required for testing this. I am dealing with bug 514431 in Papyrus-RT, observed by a user running * Windows 10 (I don't know which service release, if Windows even has such) * Java SE 8 u121 * Neon.3 * Papyrus-RT 0.9 He subsequently installed GMF 1.10.1.v201703310734 and found no change in the menu problem. Sorry for the churn. It turns out that my user's attempt to update to GMF Run-time 1.10.1 was ineffectual: only the newer versions of some source features were installed; the binaries weren't updated at all. So, I'll resolve again on the expectation that the problem is fixed by this release. I'll report back if I can get confirmation to verify the bug. > @Stefan, @Martin: can you check if the build at
> http://download.eclipse.org/modeling/gmp/gmf-runtime/updates/releases/
> R201703310734 fixes the issue for you?
>
Hi,
I am afraid I don't have access to this kind of machine and netiher does anyone in our test org. We are trying to get one, but that will most likely take some time....
(In reply to Martin Axelsson from comment #21) > > @Stefan, @Martin: can you check if the build at > > http://download.eclipse.org/modeling/gmp/gmf-runtime/updates/releases/ > > R201703310734 fixes the issue for you? > > > Hi, > I am afraid I don't have access to this kind of machine and netiher does > anyone in our test org. We are trying to get one, but that will most likely > take some time.... Thanks Martin, but given Christian's last comment, it can probably wait. Apparently everyone who has seen the bug first-hand has confirmed the new version fixes it. The reason we reopened may have been a false alarm. |