Workbench Menu/Toolbars with Runtime Envisage Plugin

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Workbench Menu/Toolbars with Runtime Envisage Plugin

ericjmcd
I want to register an Envisage Plugin at runtime (seems to work fine) except that Workbench has already created its toolbars and menubar.  Is there a clean way to add (and remove) actions after startup?

I want to do this because I plan to have many (6-10?) plugins that depend on the configuration of an attached piece of hardware. Some of the plugins will be used and some won't.  Furthermore, the state of the hardware dictates what actions should be added to workbench.

This might be easier in Tasks, but since I really like the existing LoggerView, TextEditor, PythonShell plugins that already work in Workbench, I don't want to try out Tasks (it's also a bit too cutting edge for me).

Thanks,
Eric McDonald (a recent Enthought/Traits convert)

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Workbench Menu/Toolbars with Runtime Envisage Plugin

Martin Chilvers
Hi Eric,

 From memory, I don't think the workbench supports dynamic additions to
the toolbars and menubar once the main window has been created, although
it might depend on the backend... Are you using wx or Qt?

Martin

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Workbench Menu/Toolbars with Runtime Envisage Plugin

ericjmcd
I'm using Qt. I was able to dive down enough that I can enable/disable and hide/show them so I can probably add them but it will be ugly.  Also, it looks like adding a plugin at runtime doesn't work right in other areas - i.e. application.get_service() doesn't seem to find it.

This is the code snippet that I hope would start/register the plugin via an Action:
class TestAction(pfact.Action):
    name='&Test Action'
    def perform(self, event):
        logger.info('Adding plugin at runtime')
        from test_plugin import TestPlugin
        self.window.application.add_plugin(TestPlugin())
        self.window.application.start_plugin(plugin_id='test_plugin')

However, it apparently doesn't register itself for any? of the extension points it tries to contribute to. (services, action_sets, etc.).  I'm guessing that add_plugin/start_plugin are not meant to be called after construction.  I guess this is one of the biggest problems with looking at source code in lieu of documentation.

I'd be happy to take any advice on how to implement runtime contributions to envisage/workbench.

Thanks,
Eric
Reply | Threaded
Open this post in threaded view
|

Re: Workbench Menu/Toolbars with Runtime Envisage Plugin

Martin Chilvers
Hi Eric,

On 03/04/2013 00:36, ericjmcd wrote:
> I'm using Qt. I was able to dive down enough that I can enable/disable and
> hide/show them so I can probably add them but it will be ugly.  Also, it
> looks like adding a plugin at runtime doesn't work right in other areas -
> i.e. application.get_service() doesn't seem to find it.

Hot addition of plugins works... the problem is usually that plugins
don't repond when contributions have been added/removed (which is the
hard part... for example, what should happen if a plugin disappears and
takes a view/editor that is already open etc). If you have an example of
a service not being picked up after a plugin has been loaded then I'd be
interested to have a look at the code as that should work (and the core
of Envisage is *heavily* used and well-tested).

> This is the code snippet that I hope would start/register the plugin via an
> Action:
> class TestAction(pfact.Action):
>      name='&Test Action'
>      def perform(self, event):
>          logger.info('Adding plugin at runtime')
>          from test_plugin import TestPlugin
>          self.window.application.add_plugin(TestPlugin())
>          self.window.application.start_plugin(plugin_id='test_plugin')
>
> However, it apparently doesn't register itself for any? of the extension
> points it tries to contribute to. (services, action_sets, etc.).  I'm
> guessing that add_plugin/start_plugin are not meant to be called after
> construction.  I guess this is one of the biggest problems with looking at
> source code in lieu of documentation.

What do you mean by 'doesn't register itself'? Any extension points that
the plugin contributes to should be updated and an appropriate event
thrown for the plugins that offered the extension point (as I said - it
is up to the plugins whether or not they respond).

Have you read the documentation that comes with EPD? They are not great
(I wrote them ;^), but they cover the basic principles well enough
(IMHO!), although they don't cover hot addition/removal of plugins 8^(

> I'd be happy to take any advice on how to implement runtime contributions to
> envisage/workbench.

If you could send me the smallest possible example of a runtime addition
failing then I'll happily take a look at it.

Thanks!

Martin

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Workbench Menu/Toolbars with Runtime Envisage Plugin

Corran Webster
In reply to this post by ericjmcd
Hi Eric,

I'm not entirely sure what the constraints on your technology choices are, but if you are on Qt you are probably are better using Tasks rather than Workbench.  At this point Tasks is fairly stable, and was designed explicitly for the use-cases that you are considering.  And if you are reasonably happy with the existing Workbench plugins, it's probably not a huge effort to port them to Tasks.

If you are constrained to Workbench, take care as the Qt Workbench code is not particularly pretty, and when I've worked down at that level I've found little bugs that have been hard to deal with.  Tasks is effectively a reaction to the shortcomings of Workbench with Qt.

But if you have to use Qt Workbench, listen to Martin :)

-- Corran




On Tue, Apr 2, 2013 at 6:36 PM, ericjmcd <[hidden email]> wrote:
I'm using Qt. I was able to dive down enough that I can enable/disable and
hide/show them so I can probably add them but it will be ugly.  Also, it
looks like adding a plugin at runtime doesn't work right in other areas -
i.e. application.get_service() doesn't seem to find it.

This is the code snippet that I hope would start/register the plugin via an
Action:
class TestAction(pfact.Action):
    name='&Test Action'
    def perform(self, event):
        logger.info('Adding plugin at runtime')
        from test_plugin import TestPlugin
        self.window.application.add_plugin(TestPlugin())
        self.window.application.start_plugin(plugin_id='test_plugin')

However, it apparently doesn't register itself for any? of the extension
points it tries to contribute to. (services, action_sets, etc.).  I'm
guessing that add_plugin/start_plugin are not meant to be called after
construction.  I guess this is one of the biggest problems with looking at
source code in lieu of documentation.

I'd be happy to take any advice on how to implement runtime contributions to
envisage/workbench.

Thanks,
Eric




--
View this message in context: http://enthought-dev.117412.n3.nabble.com/Workbench-Menu-Toolbars-with-Runtime-Envisage-Plugin-tp4026321p4026345.html
Sent from the Enthought Dev mailing list archive at Nabble.com.
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Workbench Menu/Toolbars with Runtime Envisage Plugin

ericjmcd
In reply to this post by Martin Chilvers
Martin,

Thanks for the detailed response.  I had thought that Workbench would handle these dynamic changes so that was my issue.

I've started on a new Tasks application where I have one Plugin alter its contributions to another's extension point at runtime and am having trouble catching the event in the provider Plugin. I thought
the below would work.  Any idea what I doing wrong? I can't catch the change in the ProviderPlugin.

class ProvPlugin(Plugin):

    sources = ExtensionPoint(List(Tuple), id=SOURCES)
    @tr.on_trait_change('extension_point_changed')
    def update_sources(self, obj, name, event):
        #This doesn't catch the below contribution

class ContribPlugin(Plugin):
    sources = List(contributes_to=SOURCES)
    def runtime_contribution(self):
        self.sources.append(...) # I see a debug message like this:
# DEBUG:envisage.provider_extension_registry:provider <<...ContribPlugin object >> extension point changed


Thanks,
Eric
Reply | Threaded
Open this post in threaded view
|

Re: Workbench Menu/Toolbars with Runtime Envisage Plugin

Martin Chilvers
Hi Eric,

On 18/08/2013 23:45, ericjmcd wrote:

> I've started on a new Tasks application where I have one Plugin alter its
> contributions to another's extension point at runtime and am having trouble
> catching the event in the provider Plugin. I thought
> the below would work.  Any idea what I doing wrong? I can't catch the change
> in the ProviderPlugin.
>
> class ProvPlugin(Plugin):
>
>      sources = ExtensionPoint(List(Tuple), id=SOURCES)
>      @tr.on_trait_change('extension_point_changed')

Extension points behave just like a normal traits list (they are simply
a list that happens to get its items from a bunch of plugins!), so the
line above should be:-

@tr.on_trait_change('sources_items')

>      def update_sources(self, obj, name, event):
>          #This doesn't catch the below contribution
>
> class ContribPlugin(Plugin):
>      sources = List(contributes_to=SOURCES)
>      def runtime_contribution(self):
>          self.sources.append(...) # I see a debug message like this:
> # DEBUG:envisage.provider_extension_registry:provider <<...ContribPlugin
> object >> extension point changed

Hope that helps!

Martin

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Workbench Menu/Toolbars with Runtime Envisage Plugin

ericjmcd
Martin,

Thanks again.  I had tried 'sources' but forgot it was a list.  That fixed it.

Eric