Re: [platform-ui-dev] Context API confusion (very long)

[Randy Hudson <hudsonr@xxxxxxxxxx>]

So after digging around some more, I'm
starting to think that Keybindings might work in the GEF palette. For example,
the key "M" will activate the "marquee" tool, etc.
 As I mentioned before, I don't want the key "M" to be consumed
when a widget like a text control has focus.  So I'm wondering if
I can't use contexts as a way to enabled and disable all of the keybindings
associated with the palette.  When a cell editor is activated, the
"palette shortcuts" context will be removed.  Also, this
context might be permanently enabled for the Palette View, and potentially
the Outline Page.

It takes some real digging to find the
"context" equivalent for changing scopes:
IWorkbenchPartSite.getKeybindingService().setScopes(String[]
);

For a while you had to call getAdapter()
on the site.  Now it's even more obscure, you have to go to a global
support object.  I'm confused.  Why isn't the new contexts stuff
centered around the site's keybinding service, similar to contexts before?

I liked the old interface names better.
 Context Manager and Context Support sound like exactly the same thing.
 But really one is a read-only object, and the other gives you power
to do stuff.  And having the "mutable" one extend the read-only
one is more convenient IMHO.

3.0 is like a complete change.  It
builds on nothing you are familiar with.  In 2.1, everything was attainable
from the part site.  Now, if I want to enable a context for just my
view or editor, I can't go to my PartSite, I have to go to some global
place, and add an entry which has my partsite specified as a parameter.
 And I have no idea if I need to clean that up.  Will the entry
get removed when the part is destroyed?  Who knows.

It looks like a context can also be
bound to a perspective.  Suppose the debug team binds "Step Over"
to their default perspective.  If the user has his own custom debug
perspective activated, then that keybinding would stop working?

I would like to propose that this stuff
be centralized around the Site or its keybinding service.  If I want
to listen to context changes, I may only be interested when my View's contexts
change.  When I want to change the context, it is most likely a change
localized to the current workbench part (or sub-part if that idea ever
takes off :-).  For those composing workbench parts, e.g. multi-page
editors, they will likely have to reimplement the context support mechanism
locally.

-randy