Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 54296

Summary:	[RCP] Presentation API and implementation needs to nail down when setFocus is called
Product:	[Eclipse Project] Platform	Reporter:	Nick Edgar <n.a.edgar>
Component:	UI	Assignee:	Stefan Xenos <sxenos>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	P2	CC:	michaelvanmeekeren
Version:	3.0	Keywords:	helpwanted
Target Milestone:	3.0 RC2
Hardware:	PC
OS:	Windows 2000
Whiteboard:
Bug Depends on:	55816, 56378, 56979, 57659, 58030, 60970, 65667
Bug Blocks:

Description Nick Edgar

2004-03-10 10:52:09 EST

build I20050303 + latest from head

Stefan asked me to log the following as a PR.

I noticed that BasicStackPresentation.selectPart sometimes sets focus, contrary 
to its spec.  selectPart should only select the appropriate tab (or whatever 
the affordance is for selecting different parts) and show the corresponding 
part with updated bounds.  This is needed so that a view can be shown but not 
activated (see IWorkbenchPage.showView(String, String, int).

There are three cases that need to be handled:

1. A new part is opened via showView.  Should it be given focus, and who's 
responsible?

2. The user clicks on the tab (or whatever) in the presentation so the new part 
should be activated.  Who's responsible?

3. The user clicks on the part's control (or descendant), giving it focus.  The 
presentation needs to be told that it is active (and if another presentation is 
active, it needs to be deactivated).  Actually, this should work the same 
whether or not the part's control actually takes focus (e.g. the empty Outline 
case, where it's just a Label).  SWT's Activate event handles both these 
cases.  This can presumably all be handled by the Workbench, and the 
presentation just be notified via setActive.  And in this case, the 
presentation should not change focus from where the user clicked.  There is 
probably a subtlety here if the part's control doesn't actually take focus.  
Focus should not be left in the old part in this case.  But this could also be 
handled by the Workbench.

Comment 1 Stefan Xenos

2004-03-25 17:07:23 EST

I believe the following is desirable:

1. Focus should be set by the workbench when opening a view.

2. I suppose this is open for discussion, but I think it would be reasonable for
the presentation to set focus when the user clicks on some presentation-managed
control (like the tabs or chevron).

3. I agree that the workbench should handle this case.

Comment 2 Stefan Xenos

2004-03-26 10:59:35 EST

Is this still M8 critical?

Comment 3 Nick Edgar

2004-03-26 11:47:58 EST

There are still some focus problems, but we'll live with them for M8.
Should address them all for M9.  Let's use this PR as the gathering point and
mark specific PRs as blocking this one.

Comment 4 Michael Van Meekeren

2004-04-12 17:25:05 EDT

Pointing out the obvious but I think our plan here needs to (where appropriate) 
do exactly what 2.1 did.  Obviously somethings are new but the goal is for 
things that are part of 2.1.x they should remain the same.

Comment 5 Nick Edgar

2004-05-11 17:07:04 EDT

Found another issue:

In response to a part's control gaining focus, PartPane.requestActivation calls
page.setActivePart, but this results in part.setFocus() being called.
This should only be called when switching parts via other means than clicking
within the part itself.

Comment 6 Michael Van Meekeren

2004-05-25 15:25:47 EDT

Need to finalize this for RC1.

Comment 7 Stefan Xenos

2004-05-28 09:41:17 EDT

Note: we need to deal with the case where the active part is closed. 

Currently, we temporarily move focus to a bogus widget until the next part in
the activation list becomes active and grabs focus. This degrades performance,
causes flicker, blah, blah, blah. It isn't a regression (Eclipse 2.1 used this
pattern too), but the pattern is wrong. There should be exactly one focus change
when you close a part.

Comment 8 Michael Van Meekeren

2004-06-11 10:02:40 EDT

remove 59511 as a blocker for this as it is a separate bug.

Comment 9 Michael Van Meekeren

2004-06-11 10:02:54 EDT

nick can we close this?

Comment 10 Nick Edgar

2004-06-11 10:14:43 EDT

Yes.  If there are further focus problems, we'll open new PRs.

Comment 11 Nick Edgar

2004-06-11 10:14:55 EDT

Closing.