Community
Participate
Working Groups
I20080605-1800 With a slow connection to a CVS server (e.g. while doing a batch update in parallel), double-click an incoming change in the Synchronize view. A compare editor is opened and its editor tab is drawn as active part. But at the same time, the tree in the Synchronize view still has the keyboard focus (although the view looks inactive). => Expected: Compare editor should take focus immediately. I guess its IWorkbenchPart#setFocus() method needs to call forceFocus() on the content control in case the content to compare is not yet available. After a while, the content area of the editor changes from gray to white with text "Initializing...", but the compare editor still does not have the keyboard focus. The editor only takes focus when the content is finally loaded and the compare panes are shown.
Markus is there a reason why you want the editor to have focus? Are you missing a concrete key binding? Ctrl+W seems to work fine...
> Markus is there a reason why you want the editor to have focus? Yes. The keyboard focus should always be inside the part whose tab is active. Everything else is confusing. My concrete scenario: I often skim over incoming changes (using arrow keys to navigate the tree). When I want to look at a change, I press the Enter key. When I now continue navigating the tree to find other changes I want to see, the compare editor steals my focus after a delay of unpredictable duration. If the focus went to the editor right away, then the situation would be clear: To continue navigating in the Synchronize view, I have to activate the Synchronize view first (e.g. by clicking the tree, or via Alt+Shift+Q Y, or via Ctrl+F7).
One more thing I observed: in the "Single Click" opening mode the focus stays on the Sync View, which also has some advantages. Which of these two approaches should we choose? In my opinion loosing the focus while in the "Single Click" mode might be quite confusing, especially when "Select on hover" option is also on. I belive this will result in loosing focus just for a while. Which makes think that the focus should stay in the Sync View in the "Double Click" mode too. What do you think Markus?
Up to now, double-click on a view element always gave focus to the newly opened editor. This should not be changed now. Re single-click: There's a help document "Honoring single click support", but it misses some cases (e.g. what should be done when the view is a fast view). I don't use single-click, and I can't give you any answers on that (see bug 38470 comment 8). Maybe Dani has an opinion.
>Up to now, double-click on a view element always gave focus to the newly opened >editor. This should not be changed now. If you meant "up to now, in DOUBLE_CLICK MODE..." then that's true and should not be changed as this is the rule for all views. In single-click mode all views keep the focus on single-click *and* on double double-click (see bug 45186). Modifying this behavior for a particular view is a no-go.
(In reply to comment #5) > >Up to now, double-click on a view element always gave focus to the newly opened > >editor. This should not be changed now. > If you meant "up to now, in DOUBLE_CLICK MODE..." then that's true and should > not be changed as this is the rule for all views. In single-click mode all > views keep the focus on single-click *and* on double double-click (see bug > 45186). Modifying this behavior for a particular view is a no-go. Fair enough, a patch for this bug should only fix what Markus described in comment 0 (keeping focus on a view for a while after double-clicking). Moreover, it should be limited only to the Compare Editor and/or Sync view. Thanks for your opinions.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
