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

Bug 144019

Summary: [KeyBindings] Constructed context shows in Keys pref page
Product: [Eclipse Project] Platform Reporter: Nick Edgar <n.a.edgar>
Component: DebugAssignee: Darin Wright <darin.eclipse>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: bokowski, darin.eclipse, pwebster
Version: 3.2   
Target Milestone: 3.3 RC1   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on: 176235    
Bug Blocks:    
Attachments:
Description Flags
Fix none

Description Nick Edgar CLA 2006-05-26 14:48:29 EDT 
3.2 RC5

- while self-hosting under debug, I went to the Keys pref page in my host
- noticed that When field has an extra item at the end: "org.eclipse.pde.ui.RuntimeWorkbench.org.eclipse.debug.ui.DebugPerspective

I guess this is a dynamic context for the progressive exposure of debug views.
It should probably not show up at all in the Keys pref page (if possible).  If that's not possible, perhaps it should have a human-readable name.
Comment 1 Darin Wright CLA 2006-07-26 16:08:11 EDT 
Paul, the debugger creates contexts on the fly to keep track of which pespectives it has activated views in, for which debug sessions. These contexts are not intended for user consumption. Is there anyway we can mark contexts for "internal use"?
Comment 2 Paul Webster CLA 2006-07-26 16:55:03 EDT 
Currently there's no way to do that using the org.eclipse.ui.contexts or the IContextService.  I'm hesitant to add that as some kind of attribute on a Context, although it might end up being part of the solution.

Another option that comes to mind (although I shudder at the thought) is some kind of context filter ...  maybe an optional way of retrieving contexts?  Would it be close to the key page (and maybe reusable) or close to the IContextService itself ... hmmm?

PW
Comment 3 Michael Rennie CLA 2006-09-19 17:42:38 EDT 
kicking it over to UI.
Comment 4 Darin Wright CLA 2006-09-19 17:46:31 EDT 
marking as enhancement request to support contexts marked for 'internal use'.
Comment 5 Paul Webster CLA 2006-09-19 21:26:56 EDT 
Hmmm, I've been giving this some thought.  I'd hoped to filter keybinding so that they must inherit from dialogAndWindows, but it's valid to have other active contexts with no parent for keybindings.

I'm leaning towards adding a default filter to the new Keybindings page.  Just like PDE, I'd default it to context IDs that contains *.internal.*

Later,
PW
Comment 6 Darin Wright CLA 2006-09-19 22:12:50 EDT 
Using *.internal.* would work for us - we could split the config type with the perspective using ".internal.".
Comment 7 Paul Webster CLA 2007-04-30 14:08:48 EDT 
(In reply to comment #6)
> Using *.internal.* would work for us - we could split the config type with the
> perspective using ".internal.".
> 

Is this still do-able?  The new keys preference page now filters contexts with .internal. in their ID by default.

PW
Comment 8 Darin Wright CLA 2007-04-30 14:15:45 EDT 
Move the bug to platfrom/debug if you want us to take ownership now. We might consider this in 3.3 RC1.
Comment 9 Curtis Windatt CLA 2007-05-03 13:20:51 EDT 
Created attachment 65806 [details]
Fix

Patch changes the "." to ".internal.".

The context still shows on the legacy key binding page.
Comment 10 Curtis Windatt CLA 2007-05-07 10:36:16 EDT 
Darin, please review and apply the patch.
Comment 11 Darin Wright CLA 2007-05-07 12:52:26 EDT 
+1. Released patch. Added null check back into the code (for targetId).
Comment 12 Darin Wright CLA 2007-05-07 12:52:42 EDT 
Verified.