Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [platform-ui-dev] Proper way to inherit key binding scopes

> -----Original Message-----
> From: Douglas Pollock [mailto:douglas.pollock@xxxxxxxx]
> Sent: Thursday, May 06, 2004 4:39 PM
> To: platform-ui-dev@xxxxxxxxxxx
> Subject: Re: [platform-ui-dev] Proper way to inherit key 
> binding scopes
> On Thursday 06 May 2004 15:07, Thomas Fletcher wrote:
> > Can I also get an answer to the basic question of "should I 
> have to be
> > hard coding" multiple inheritances in my editor or should it all be
> > resolved using the extension points.  I'm assuming that 
> from your response
> > it should be inheriting the values from the extension point.
> Sorry, I shouldn't have been so short with my previous reply. 
>  I'm feeling a little bit swamped right now.

And you are on the inside of the loop! =;-)
> You shouldn't have to hard-code inheritance for key bindings.  
> WorkbenchContextSupport.createContextTree() provides a facility for 
> converting a short list of contexts into the complete tree of 
> contexts (including parents).  This method is used by 
> WorkbenchCommandSupport to pass a complete tree into the key binding

Excellent, then I know that the code I've got doesn't need to be 
adjusted, just the one scope/context change should be required.
> Out of curiousity, which build are you using?  Up until 
> I200405050200, there 
> were issues with several issues with inheritance of contexts 
> -- especially as 
> they related to key bindings.  If you are still having 
> problems with the new 
> API and this build (or later), please file a bug.

The CDT (C/C++ Development Tools) project is attempting to only
use the stable milestone builds, so I'm using M8, but that is 
providing to be tricky and leaving us out of the loop on some 
significant API changes that occur late in milestone releases.    
> > Also ... how come this <scope to <context extention point change
> > has not been documented as part of the 3.0 editor migration 
> (the extension
> > point information still says since 2.1 and the code 
> examples all still
> > use <scope)  Is the plan to deprecate <scope in favour of 
> <context?  Are
> > all of the other references to scope (ie in the commands) 
> also going to
> > be deprecated and changed to context?  What about parent vs 
> parentId in
> > the extention point description?
> I've inherited this code very recently, and am a little bit 
> at a loss as to what to say about this.  The scopes were pulled 
> out back in June 2003.  The "acceleratorScopes" extension point was 
> pulled out, and then put back in.  
> Unfortunately, tracing through the code, it appears that the 
> deprecation support for acceleratorScopes trails off at some point.  
> I'd  be surprised if it works.  "scopes" definitely do not work.

Well that would have been _very_ early in the Eclipse 3.0 migration
> In talking with some other developers on the Platform UI 
> team, we'd decided to put deprecated support for the scopes API back in
for 3.0, 
> and will be moving toward this over the next few days.  This bug is being 
> tracked as Bug 61310
> I'd like to apologize for any trouble this has caused you.

No trouble yet ... we are just trying to play catch-up =;-) Thanks for the
bug I'll sign up!
> I'm not aware of which code examples you are speaking about.  
> If you could point me to them, I would try to update them to the 
> new API.

I should have said documentation samples.  The one which come to mind
are the ones you find if you search for "scope" in the documentation (at
the M8 documentation).  The first two hits ("Scopes" and "Other editor
both still use <scope instead of <context, and then there are a number of
areas which still use Scopes even though they aren't present in the user 
interface any more.  

Does that mean that you are also going to make the API in the editor
initializeKeyBindingScopes() --> initializeKeyBindingContexts()
setKeyBindingScopes() --> setKeyBindingContexts()

Just curious, it would make sense if you are going to freeze the API soon to

make the nomenclature consistant.


Back to the top