[platform-ui-dev] Some answers to Randy's context and command questions

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

> EnabledSubmission is a strange name for a class.
I got confused when
> I started having a conversation about disabling my 
> EnabledSubmissions, which are still enabledSubmissions, even when
> they're disabled.  Maybe there is a better name for this object
... 
> it's really more of a "ContextContext" ;-). 
> 
> Anyway, it seems more convenient and easier to read code if you 
> could do something like: 
> 
> contextSupport.enableContext(String) 
>   or 
> contextSupport.disableContext(String) 
>   or 
> workbenchPartSite.enableContext(String) 
> 
> that way you could avoid having to name this class altogether. 

If you read all of my post to Jared, you will see
that I do not say clients can enable or disable contexts. Rather, I say
that clients can request that a context be enabled, or withdraw that request.
There is a difference. The set of enabled contexts is a shared (and protected)
resource. One client cannot disable a context that another client has enabled.

'EnabledSubmission' encapsulates this request. With
this class, you can 'submit' your request to the workbench to 'enable'
a context. 

[on a side note: There is a very similar (and much
larger..) system for command management currently being developed that
uses this model as well. One can specify handlers for commands in the same
way, using a class named 'HandlerSubmission', without going through the
existing jface 'Action' mechanisms]

In summary, just say to yourself 'i should submit
a request to enable a context' and 'i should withdraw that request' and
hopefullly no one will ever have to see a class named 'ContextContext'..


> > a. Make sure to keep around your reference
to enabledSubmission after you 
> > request that a context be enabled. You need this reference to
> withdraw your request later. 
> 
> Why is that?  It looks like equals() and hashCode() are implemented
> correctly. 

You found a bug here which is now fixed. EnabledSubmission.equals()
was removed to ensure instances are compared by reference only. This ensures
that clients can only withdraw requests they created.


> Another problem we ran into was trying to enable
a context for only 
> our editor's outline page.  Our page has no IWorkbenchPartSite
> associated with it.  So what is the technique for enabling a
context
> for just a page?  It seems like it should be IPageSite.
> getKeybindingService().enableContext(String).  Related to that,
how 
> can our page even get the KeybindingService? I'm not sure if my 
> editorpart's registered actions are available in my outline page.

The fact that the workbench doesn't recognize anything
more granular than the 'part' is an existing limitation that has nothing
to do with commands or contexts. That being said, we have recently made
nested KeyBindingServices for multi page editors, and I beleive Doug Pollock
is duplicating this work for page books. 


> 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. 

1. What old interface names? 

2. IContextManager and all its related interfaces
(95% of the context code) has no dependancies on the workbench, that's
why its separate from IWorkbenchContextSupport. IWorkbenchContextSupport
is the root of all the context support the workbench offers - ContextManager
is part of it, and other workbench specific context stuff goes here as
well (like the EnabledSubmissions..). It's not intentionally divided by
mutable v. non-mutable.

Again, the command system, also new for 3.0, uses
a similar model. IWorkbench.getCommandSupport() has more methods than IWorkbench.getContextSupport(),
and perhaps is a better example of why this makes sense.

One option is to flatten IContextManager's methods
into IWorkbenchContextSupport, but then I'd have to make code changes in
workbench as IContextManager evolves.


> 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. 
> 
> 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. 

IKeyBindingService still works fine and currently
reroutes through the global methods automatically if that's what you want
to use. We may decide to un-deprecate IKeyBindingService for this purpose
if we don't provide an equivalent part site API with the more appropriate
names (like say ICommandPartSiteService or IContextPartSiteService).

Either way, we will take these points into consideration,
and make the API clear on how clean up should work. (fwiw, you should remove
any submissions on disposal)

 
> 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? 

This is a good point, thanks. I don't have an answer
for you yet.