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

[Randy Hudson <hudsonr@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.

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.

-Randy




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

Chris McLaren <Chris_McLaren@xxxxxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 02/24/2004 03:06 PM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-ui-dev] Context API confusion (very long)

Easy answers for you. All of this was radically simplified this week. (I
got debug from head and checked out how you were using things so I knew
I wouldn't break the build) 

1. Your one and only entry point to the contexts API:
IWorkbenchContextSupport contextSupport = IWorkbench.getContextSupport()

2. You can get the *real* context manager for the workbench like this (you
should not be creating your own, or it won't play with keybindings, etc..):
IContextManager contextManager = contextSupport.getContextManager();

3. To request that a context be enabled: 
EnabledSubmission enabledSubmission = new EnabledSubmission(null, null,
"myContextId"); 
IWorkbench.getContextSupport().addEnabledSubmission(Collections.singletonList(enabledSubmission));

4. To withdraw that request: 
IWorkbench.getContextSupport().removeEnabledSubmission(Collections.singletonList(enabledSubmission));


Extra notes: 

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. 

b. Withdrawing your request doesn't necessarily mean your context will
be disabled - some other plugin may have put in an EnabledSubmission for
this context as well. The context manager enables a context if one or more
plugins request it to be enabled. (notice that you do not have access to
IMutableContextManager.setEnabledContextsIds, even if you try to cast contextManager
to it). The context manager protects itself - you must submit a request
in the manner described above. 

c. The first two parameters of enabled submission allow you to specify
that the workbench should only enable your context when a certain part
and/or perspective is active, a convenience to use if you choose (the workbench
will take care of the rest), or you can manage this yourself using the
global listeners. Using null and null as I have done in this example means
you want it enabled independent of what part or perspective is active).

d. Notice the term is now 'enabled'. The term 'active' should no longer
be used. I will double check the API to make sure of this for clarity..


That should be pretty much everything you need to know (a lot simpler,
eh?). Let me know what I missed after you digest these changes.
Chris.