Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] Custom Event Support #2965

Closed
tjjfvi opened this issue Dec 22, 2018 · 9 comments
Closed

[Request] Custom Event Support #2965

tjjfvi opened this issue Dec 22, 2018 · 9 comments
Labels
done Done but not yet released request Feature request
Milestone

Comments

@tjjfvi
Copy link

tjjfvi commented Dec 22, 2018

Is your feature request related to a problem? Please describe.
It is not related to a problem.

Describe the solution you'd like
If OctoPrint could support custom events, triggered by plugins, that would be great. If it already (documented or not) supports this, that's even better; I don't need to wait :)

Describe alternatives you've considered
I have not thought of any alternatives.

Additional context
I recently created a plugin for OctoPrint that notififies via IFTTT when the printer sends N or more busy signals. Obviously, that is a very specialized plugin; it would most likely be much more useful to have two plugins: one that adds a EchoBusy event and one that sends some or all events to IFTTT.

I have looked into the source/docs some and found that a plugin could run self._event_bus.fire("MyHappyCustomEvent", dict(payload_key=payload_val)) and it would (seemingly) work and not destroy OctoPrint, but I haven't thoroughly tested it.

@GitIssueBot GitIssueBot added request Feature request and removed request Feature request labels Dec 22, 2018
@tjjfvi
Copy link
Author

tjjfvi commented Dec 27, 2018

My example with self._event_bus doesn't work on the client-side (i.e. the client will not call a viewmodel's self.onEventMyHappyCustomEvent, but will for self.onEventPrintStarted). I don't know if there is a workaround other than manually self._plugin_manager.send_plugin_message(...)ing.

@foosel foosel added this to the 1.3.11 milestone Jan 10, 2019
@foosel
Copy link
Member

foosel commented Jan 10, 2019

In theory it should work to set the new event on octoprint.events.Events, that will make it register in the client too, but I agree, a more straightforward hook or something to accomplish that is really needed.

@tjjfvi
Copy link
Author

tjjfvi commented Jan 10, 2019

Ah, I hadn't seen that; maybe just throwing a paragraph about using that and the self._event_bus.fire to make custom events is enough?

@foosel
Copy link
Member

foosel commented Jan 15, 2019

maybe just throwing a paragraph about using that and the self._event_bus.fire to make custom events is enough?

In theory, but monkey patching is a bit hackish. By providing a defined hook namespace collisions could also be avoided (imagine two plugins deciding they want to define an event SOMETHING_HAPPENED...).

foosel added a commit that referenced this issue Jan 15, 2019
@foosel
Copy link
Member

foosel commented Jan 15, 2019

The above commit adds a new hook octoprint.events.register_custom_events that allows to register custom events by plugins. Documentation will soon be available here, once the doc build is through.

Commit is pushed to maintenance, soon devel and will be released with 1.3.11.

@foosel foosel added the done Done but not yet released label Jan 15, 2019
@tjjfvi
Copy link
Author

tjjfvi commented Feb 25, 2019

@foosel: As I read it, it seems that you can only register events for plugin_myhappyplugin_my_happy_event_name. Would it be possible to also allow my_happy_event_name as an alias (only to be used by user-facing apis), assuming no conflicts?

@foosel
Copy link
Member

foosel commented Mar 25, 2019

Would it be possible to also allow my_happy_event_name as an alias (only to be used by user-facing apis), assuming no conflicts?

Oops, I somehow overlooked this question. Doing it like it's implemented now keeps it consistent with other plugin extended things, e.g. templates, div-ids, permissions in 1.4.0.dev and so on. Allowing customized event names without prefix will only cause issues and frustration down the road if I need a conflicting event name.

@foosel
Copy link
Member

foosel commented May 15, 2019

1.3.11 was released yesterday.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
done Done but not yet released request Feature request
Projects
None yet
Development

No branches or pull requests

3 participants