GNOME Bugzilla – Bug 311688
Add plugin interface
Last modified: 2021-05-17 15:48:50 UTC
If plugins could be created which were called on start/stop playback, rip completed, etc, then various cool things could be done without much hastle. * M3U creating * Audioscrobbler posting * DBus signals which RB/Muine can listen for
Ross: Adding plugin interface is a coool thing,.. Could you create a sample plugin, so that it'll be useful for others to write new plugins. :)
Created attachment 88296 [details] Sample screenshot Hi, I ported gedit/epyphany/eog plugin system to Sound Juicer. It is still a bit rough, but it starts working. In the next few days I will post a patch. Todo: - write a SjWindow object - add support for python plugins - fix a little problem with plugin starting - I'm sure there is something else...
Oh, nice. What sort of hooks are exposed for the plugins?
Ross, no one at the moment, but the plugin can register its own signal handler for signals emitted by libjuicer or any other sj component. For testing purpose I was able react to media insertion, registering a signal handler for "media-added" signal from NautilusBurnDrive.
Created attachment 88367 [details] [review] sj-plugin.patch Here is a first attempt to add plugin system. The .glade file seems deeply modified, but it is just reindentation due to GtkNotebook adding (I did it by hand with a text editor). You can avoid "make install", just copy libsample.a libsample.la libsample.so you can find in plugins/sample/.libs and sample.sj-plugin you can find in plugins/sample to ~/.gnome2/sound-juicer/plugins and run sound-juicer from src directory. Now plugins need a real SjWindow, or better SjApp, to interact with :)
> Todo: > - write a SjWindow object > - add support for python plugins > - fix a little problem with plugin starting Oh, the problem with plugin starting is now fixed.
Woo! Maybe I should install Review Board to review this beasty.
This is tricky. Because plugins are totally useless until there is a SjWindow, I don't want to land this in trunk until it is usable. However, I don't like maintaining huge patches. What do you think about using bazaar and branching the SJ repository on launchpad? I have in a private bzr branch a start of a SjWindow object from a while ago, so if you can public a bzr branch with the plugin patches in, I can merge it and we can finish SjWindow.
Ross, I have never used bazaar, but no problem public a branch with my patch applied somewhere (just tell me how I can do that). As for the patch size, most of the code is just copy & paste from gedit/eog (changing only namespaces, so the coding style doesn't follow sj's one) but there are a few places where you have to look at (i.e. sj is not a multiple windows app), I will write you a detailed report in the next few days. > I don't want to land this in trunk until it is usable. Me too :)
I've just started a branch import on launchpad, it was previously tracking CVS, which was out of date. I'll ping when it's up and running.
Today I discovered that launchpad hosts a working branch mirrored from GNOME svn. I branched from launchpad, updated and applied the patch locally (to avoid glade adding unwanted stuff I applied the glade portion by hand), created my own branch on launchpad and pushed new code into this new branch. I hope this is what you needed :) https://code.launchpad.net/~luca-cavalli/sound-juicer/sound-juicer-plugins
Oh, fab, I'll check that out.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/sound-juicer/-/issues/35.