Community
Participate
Working Groups
Build ID: IES 3.4.1 used in RAD 7.5.1 Steps To Reproduce: Our product (WebSphere Integration Developer 6.2) makes extensive use of the property sheet view to show/edit the properties of items selected in our editors. When focus is in the property sheet, pressing F1 is causing the Help View to become the active workbench part (this was not the behavior in 3.4.0 and earlier). When the Help View becomes the active part the contents of the property sheet view contributed by the editor are lost. The user is forced to re-select the item in the editor in order to continue to work on the properties they are editing. We make extensive use of F1 help to assist the user in editing properties. This regression in usability is a stop ship defect for WID 6.2 I have confirmed that this is also happening when using a RAD editor (web diagram). The attached screen shots show the effect of pressing F1 in the property sheet Note in the Before picture the help view is not the active part and the content of the properties view are maintained In the After picture the help view is the active part and the contents of the properties
This issue has been discussed with Kevin McGuire
(In reply to comment #0) > The attached screen shots show the effect of pressing F1 in the property sheet Randy, it appears you forgot the screen shots. Note: to clarify, this is a regression from 3.4 to 3.4.1. I've confirmed it: 1) Download Eclipse classic SDK for 3.4 and 3.4.1 and repeat the following steps 2) Go to Update, pick Ganymede, and select "Graphical Editors and Frameworks", click on the entire category, install, restart. 3) New->Example->Flow 4) Run an inner eclipse 5) Create a general project 6) New->Example->GEF->Flow Diagram 7) Ctrl-3, pick Properties 8) Select "Sleep" in flow diagram from 6. NOTE the Properties view shows "Name | Sleep" 9) F1 3.4: "Name | Sleep" remains in Properties view. 3.4.1: Properties view goes blank.
Created attachment 116844 [details] Changed behavior as described in defect
This appears to have been introduced as a result of the fix for bug 237326. In 3.4 the Help view did -not- activate on open; in 3.4.1 & 3.5 it does activate (which is what is causing this issue. For 3.4 I'd suggest taking the fix out. Perhaps we can figure out some way to have both fixes in the 3.5 stream but this will require some re-design work (i.e. have to prevent the Help view from changing the Property view's 'focus' even though it's becoming active).
Adding Chris for comment...
Here is a suggestion I made to our team before I realized it was a regression ;) ... This is a hard problem since the eclipse framework closely ties the properties view to the active workbench part. Possibly the following could be exploited: On part activation the properties view asks the active part if it is a IContributedContentsView and this support can be contributed via an adapter /** * The <code>PropertySheet</code> implementation of this <code>IPartListener</code> * method first sees if the active part is an <code>IContributedContentsView</code> * adapter and if so, asks it for its contributing part. */ public void partActivated(IWorkbenchPart part) { // Look for a declaratively-contributed adapter - including not yet loaded adapter factories. // See bug 86362 [PropertiesView] Can not access AdapterFactory, when plugin is not loaded. IContributedContentsView view = (IContributedContentsView) ViewsPlugin.getAdapter(part, IContributedContentsView.class, true); IWorkbenchPart source = null; if (view != null) { source = view.getContributingPart(); } if (source != null) { super.partActivated(source); } else { super.partActivated(part); } The concept of an IContributedContentsView was introduced to support views like the content outline The content outline has its contents contributed by a editor - so the editor actually contributes the support for showing properties of items selected in the outline So we could contribute an adapter that provides an IContributedContentsView for the help view It could track part activation and return the last non-IContributedContentsView part that was active prior to the help view (need to make sure it does not hold on to the reference too long) There are probably some holes here but it is likely worth a try
Thanks Randy, nice analysis. For the 3.4.2 version it's somewhat risky but as an approach to having our cake and eating it too in 3.5 it looks like a promising approach...
I agree with Eric, for 3.4.2 backing out the focus change is the way to go.
Submitted 3.4.1 patch request 129080 https://bugs.ottawa.ibm.com/show_bug.cgi?id=129080 Essentially we're requesting 237326 to be backed out of 3.4.1 as well, since the 2 adopter products are based on 3.4.1.
The short term fix for 3.4.2 and the longer term fix for 3.5 are almost certainly going to be different. I have created Bug 253977 to track the request to back out the fix for Bug 237326 in Eclipse 3.4.2. This bug should be given a target milestone of 3.5.
Downgrading from 'blocker' since there's no data loss...this is still high on my hit list though...
Created attachment 117251 [details] Exclude the HelpView from participation in the PropertySheet This patch should allow the UA fix to stay in (it's actually a severe accessibility defect) while maintaining your current work flows. If someone on the team could apply this patch and try out the various scenarios I'd really appreciate it...
Just tested this patch and it works well with no problems detected.
Thanks Chris. I'm awaiting for feedback from the WID folks to ensure that their issue is also solved...
this patch fixes the problem in WID 6.2
Beauty...Chris, have you opened some 3.4.2 (and a patch stream) defect for this ? I'm not familiar with the patch defect process so if you could give me some pointers...;-). I'll leave this defect open for now to capture our need to supply a valid API extension for this in the 3.5 stream. Just to capture the requirement: The patch currently 'wires off' the HelpView by using its id inside the PropertySheet@isImportant method. Right now it's hard-coded but it should be possible to do this through some new public API (first guess would be a fairly simple extension point allowing registration of a part id as being 'unimportant' to the properties view).
just an update...the 3.4.2 fix should be going into tonight's build. To get started on what we're going to do now the initial idea seems to be to add an extension point matching the current code (i.e, in the EP you'd simply register your view as 'unImportant' to the PropertyView). This would allow us to remove the hard-coded id. While this is a bit of a pain (having to define the view in one place and this in a separate one) it keeps the info separate from each view. One approach we talked about was to add an (optional) attribute to the org.eclipse.ui.views but we rejected that because it would infer that each view somehow 'knows' that there's a Properties view (not the case always). This approach keeps it all under the control of the Properties View (it reads the new EP...) if it's not there then no other impact...
I appreciate everyone's effort on this. I'm not sure where the state of this work is in terms of getting into IES 3.4.1, RAD 7.5.1, WID 6.2 But these products are getting very close to GM Thus we should thus make this happen ASAP I'm sure everything will work out right the first time (but just in case...)
I've verified this is working in our build. Thanks everyone.
Is there anything left to do here? Can this bug be closed?
No more issues from me
Committed in >20090416. I've carried forward the 'fix' from the 3.4.2 stream (explicit code to ignore the HelpView since we're already past API freeze.
(In reply to comment #22) > Committed in >20090416. I've carried forward the 'fix' from the 3.4.2 stream > (explicit code to ignore the HelpView since we're already past API freeze. Will something else be done for 3.6?
Thanks Remy, I've opened Bug 272564 to track this for 3.6...
*** Bug 216786 has been marked as a duplicate of this bug. ***
