Plugin Tabs

[philipstarkey]

Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

Plugins should be able to spawn tabs to easily display information along with that of devices.

I've already played around with this a bit in a branch of my repo. Before I continue development of this feature I'd like to get some opinions on the following questions:

Should a Plugin be able to spawn more than one Tab?

I think one Tab for each Plugin should be enough. It wouldn't be hard to implement more though.

Should a Plugin need to implement a Worker for the tab to work?

The current implementation of Tab in BLACS is very device centered and has lot's of device specific stuff stored in it. One problem with this among others is that each tab needs to have a worker to function properly. It would be a lot of work to separate the device specific stuff out of tabs and move it to DeviceTab. Is this something we should do or do we stick to the base class and make adjustments in a PluginTab class like my brach does?

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

I'm not sure if anything so complicated is necessary. I would advocate for following the model of the menu and notifications in plugins where the plugin just returns a list of classes to be instantiated by BLACS. It could be assumed these classes will be passed a reference to a notebook (in the same way the device tabs are) and a settings dictionary when they are instantiated by BLACS in __main__.py during plugin setup (like we do with the notification classes).

Whether these tab classes add one or more tabs to the notebook, is up to them. As is the form they take; I cant foresee the need for plugin tabs having a worker process, but the above does not preclude that.

In short, the less prescription here, the better!

---

One possible issue that needs cleaning up is the communication between notifications/menus/settings/tab classes defined in a plugin. Because BLACS handles the instantiation of those classes, they don't always have a clean way of communicating. I did some hacks (e.g. Plugin.set_notification_instances and plugin_setup_complete) but with tabs as well, that may need to be revisited so it makes sense.

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

Yeah that idea is better then mine but I'll make the list of classes a dict to that we can name the tabs.

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

• Edited issue description

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

As for the issue of communication we could pass the tabs in plugin_setup_complete maybe? For more high level communication each plugin could think of something itself as this can become very application specific. Some plugins might not even need communication and just implement a mainloop doing whatever.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

Well we can leave the communication for now. Likely you just need a way to connect Qt signals between the objects for the different parts of the plugins, but the implementation of this can be deferred until there is a specific use case.