Community
Participate
Working Groups
Using I20120314-1800 (M6) and N20120309-2000 1. With CDT installed and a CDT project (Hello world is OK), open the Open Element dialog (Ctrl+shift+t) with no text selected in the editor. 2. The text field where the element name should be entered is disabled This works correctly in I20120228-0800 with the same version of CDT (8.1.0.201203191015). So, something must've changed in the platform between I20120228-0800 and N20120309-2000.
Created attachment 212932 [details] Screenshot BTW, I reproduced this on Windows 7 and Ubuntu 10.10.
Where's the source for that dialog? org.eclipse.cdt.internal.ui.browser.opentype.ElementSelectionDialog ? Probably broken by the fix for bug 348537 PW
(In reply to comment #2) > Where's the source for that dialog? > org.eclipse.cdt.internal.ui.browser.opentype.ElementSelectionDialog ? Yes, that's the one.
(In reply to comment #2) > Where's the source for that dialog? > org.eclipse.cdt.internal.ui.browser.opentype.ElementSelectionDialog ? > > Probably broken by the fix for bug 348537 > > PW The fix for bug 348537 added behavior to disable the search text box if a call to setListElements cleared the content of the dialog. This is causing a problem for CDT because the lazyily load the content for their dialog only once the user starts typing in the filter field. I provided Pawel a test patch that resolves the issue. I guess we just need to decided where and how we want to fix this. I will attach the patch here
Created attachment 212938 [details] CDT patch This is a patch for CDT that will restore their old behavior
(In reply to comment #5) > Created attachment 212938 [details] > CDT patch > > This is a patch for CDT that will restore their old behavior Chatting with Paul, keeping the fix for bug 348537 (to disable the filter text also) is causing CDT and possibly other grief. Perhaps we could update the handleElementsChanged method to not disable the filter text as a better solution?
(In reply to comment #6) > Chatting with Paul, keeping the fix for bug 348537 (to disable the filter text > also) is causing CDT and possibly other grief. Perhaps we could update the > handleElementsChanged method to not disable the filter text as a better > solution? It's your choice. Updating CDT with your patch is not a problem (IMO).
If I'm reading this right ... this is not a blocking problem, especially with the CDT patch that could be used for M6, right? Is it anticipated to be a _blocking_ problem for anyone else? Perhaps the "improved fix" alluded to in comment 6 could go into M7, and if becomes a "blocking" problem for others before M7, a platform feature patch could be created (unofficial, just form developers workbench) and provide that for others to use to overcome the issue if it is discovered later that it does block someone. I'm writing this in response to Paul's question on mailing list "should we respin M6"? On the surface, it doesn't sound like that kind of drastic action is needed in this case? (I know, we have a tradition of having an M6a ... but ... it is a busy week!) As always, I could be missing something very obvious to others, so don't hesitate to explain or provide counter arguments of why we should have a respin. Thanks,
(In reply to comment #8) > If I'm reading this right ... this is not a blocking problem, especially with > the CDT patch that could be used for M6, right? I pushed the fix out to CDT and asked for a respin there. So you can decide to clean up the api change after M6.
(In reply to comment #8) > If I'm reading this right ... this is not a blocking problem, especially with > the CDT patch that could be used for M6, right? > It sounds like if CDT is willing to accept the patch for their M6 then we would not request a respin. Unless I hear otherwise we'll fix it in M7. Sorry for the fire-drill, but we don't want to leave CDT in the lurch :-) PW
The question is: does this affect more than CDT, or did we just test first?
(In reply to comment #8) Since there is absolutely no information on any other broken plugins or lack of thereof, the only safe course of action seems to be to respin platform M6.
(In reply to comment #11) > The question is: does this affect more than CDT, or did we just test first? You're the only ones that reported this. Hopefully other release train projects have also tested their contribution against Platform M6, but arguably we have no proof. Any other subclass that also overrode handleEmptyList() so it no longer disabled the filter would also be a good candidate for hitting this bug. There is a risk, but hopefully we would have a report by now. I'm willing to respin if this is really that serious, but with David weighing in against I'm also willing to fix it in M7. PW
-1 to respin at this point. Theoretically others could be affected but they should have raised the red flag by now. Also, it's not the release/final Juno build and M7 will contain the fix.
*** cdt git genie on behalf of Michael Rennie *** Bug 374795 - Open Element dialog (CDT) has text field disabled in 3.8M6 [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=66e13018e4dfb5ddceadf64975d8060ac2653cba
Created a github branch for the platform UI fix: https://github.com/mrennie/eclipse.platform.ui/commits/mrennie/bug374795
Released to master and R3_development: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=075265529ce2559be527601b10c38a51144b9a45 http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R3_development&id=ed55274cf0c3ed1f0ed010b28deab7a94ec025ae I've confirmed the pre-M6 CDT dialog functions now. Thanx Michael. PW
In I20120430-1800 PW
