Webtorrent-desktop: Auto subtitle loading using subtitle API

[olup]

Why not have an auto loading subtitle system - or a subtitle search in the player that search based on hash - to get a one click subs solution ? Good free API exists, and they already seem to have efficient JS wrapper.

[olup]

So i added a downloadSubtitles function and linked it to a new menu entry. For now it just get the best matching english sub from OS (opensubtitle), download it to the torrent folder and add it to the video. It works quite well, but i will keep testing it a bit.

My questions are :

• Should i submit a PR - i mean, is this a wanted feature ?
• If so should someone get a userAgent Id from OS API for this app ?
• What features should be built on top of that ? GUI for selecting in a list of 5 best subs ? Language selection ? Menu option in the bottom cc button ?

Note that if this feature gets implemented OS require some acknowledgment on the app website and all, and that also adds proprietary api in the software. Maybe not something fitted to the opensource spirit.

[feross]

@olup Thanks for looking into this feature idea. I think it's really cool, but it's not something that I think belongs in the core part of the app. You can see this issue #677 where it was considered before.

We can't add this feature to WebTorrent Desktop, because the legality of OpenSubtitles is not clear to us. Once there's a plugin system, I suppose you could build this as a plugin. But it's not something the WebTorrent team can endorse.

[codealchemist]

@olup We already have a prototype for a plugin system on #1125.
You're welcome if you want to collaborate.
:)

Cheers!

[olup]

Sounds great ! My code includes now language selection, sub choices, transparent right hand panel interface. That shouldn't be too hard to port to a plugin. I'll try some times next week.

Any docs about what is exposed as plugins hooks ? Is it the same as for zeit's hyper terminal ?

Thanks

[codealchemist]

Hey @olup, that's awesome!
Right know the plugin system only decorates window objects and menu.

We also have another PR for this feature on #722 by @alamcordeiro.
I think you guys have a similar approach for subtitle downloading.

I will work on finding a way to extend the subtitles controller and then I will let you know so you can coordinate your work on the subtitles downloader plugin.

Hopefully we will be able to merge the plugin system after some polishing and feedback from other team members and we will be able to launch it along with a subtitles plugin!
That will be awesome!

[codealchemist]

@olup, @alamcordeiro I've just pushed new stuff on #1125.
Now plugins can expose a setDispatcher method to get WebTorrent's dispatcher.
They can also expose event handlers for any dispatcher event to get notified when the event is dispatched.

We can use this to inject subtitles when checkForSubtitles is dispatched.
A subtitles plugin would need to export the method onCheckForSubtitles, which will be called each time checkForSubtitles is dispatched on WebTorrent's renderer.
To inject subs from the plugin we can use the dispatcher we set on setDispatcher by calling this.dispatch('addSubtitles', [gotSubtitles], true), which will call addSubtitles(files, autoSelect) on SubtitlesController.

Please, let me know if you have any questions.
We're one step closer to subtitles!
Cheers!

[olup]

In the plugin branch setDispatcher never got called. Moved plugins.initRender() from renderer/main to main/index and it works ok. I can't see the onCheckForSubtitles tho.

Working on the plugin then 👍

One question : is there a method to hook to the main render in order to display custom extra menus ?
And, another thing, how would you access the global state from the plugin - so that we can scan the movie opened ?

[codealchemist]

@olup I created a repo as a starting point:
https://github.com/codealchemist/webtorrent-subtitles

Already added you as collaborator there :)

On WebTorrent's plugins branch you can add this to WebTorrent's config file to load this sample plugin:

"plugins": {
    "webtorrent-subtitles": "codealchemist/webtorrent-subtitles"
  }

Right after the plugin finishes installing if you start playing a video it will complain about this.dispatch not being defined. Reloading WebTorrent fixes this.
I still need to find a fix for that (problem is the plugin is missing injections that occur when the app starts).

This plugin so far is a clone of webtorrent-transparent with the new hooks I added to support subtitles.
It already decorates the menu, so you can use that as an example to add menu items for the subtitles feature.

Another TODO for plugins is decorating the preferences view or maybe create an independent view for plugin preferences.
This one will be fun :)

[olup]

Ok cheers @codealchemist , I had started my own but let's use yours. The main questions i have right now are :

• Plugins need to access the state. Especially an automatic subs downloader - the business logic of extracting name of movie and path of torrent should be set in the plugin so that it can be changed later without touching the main app. So plugins should probably be able to subscribe to the main state in some ways.
• in the same spirit, I think all plugins would benefit in a way to hook in the main render function so that they can display menus and custom panel / modals
• In the code version i got (branch plugins), most of the plugin init functions are done in main/index.js, only initRenderer() (passing the dispatcher to the plugins) appears only in renderer/main, wich never gets called on start. Is there a specific reason why not having this called in main/index ?

[codealchemist]

@olup You're right about state.
I'm now passing state from the renderer process to the plugin.
I also updated webtorrent-subtitles repo using this.
Please, pull latest stuff from both repos and give it a try.
Thx!

About hooking into the main renderer...
So far we have basic hooks that let us interact with WebTorrent Desktop setting and reading state, getting dispatch notifications and dispatching events.
How would you further integrate into it?
Let's take the case of displaying a modal, how would you allow for a plugin to display a modal?

Also related to your third question...
I'm also starting to think that we might want to divide plugins into main and renderer processes.
Right now there's only one file with an ES6 class being instantiated for each one.
Should be a lot cleaner and easier to understand if we have something like:

webtorrent-subtitles/main.js
webtorrent-subtitles/renderer.js

What do you think?
Cheers!

[olup]

Great. Totally with you for the separation in main and renderer. Makes
perfect sense.

EDIT : No problem with initRenderer after all

[codealchemist]

I'll try to make some time during the weekend to separate plugins into main and renderer processes.

If you already started trying stuff with the current structure I hope it will be a small refactor later.
Anyway, I'll help in anyway I can.
:)

Thanks!

[codealchemist]

Hey @olup, I've just pushed changes on both repos to support independent main and renderer processes on plugins.

Beware, these are breaking changes!
Please, let me know if you need any help.

Cheers!

[olup]

No problem, i'll use the new architecture. Some questions I still can't put my head around yet with the plugin system :

• dispatcher and state in the plugin are available at render time. It's great, they are used for the OS api call. But as they are not present at init time, when the menu is cooked out of the plugin, it's not possible to call a dispatcher from menu. I feel that having dispatcher filled in the plugin also at init time makes it better.
• In the other way around, trying to find ways to organise a subtitle ui, i was trying to update the menu at runtime. But i feel that i then need the app and menu objects in my plugin accessible in the renderer part in order to apply changes. Is it the case yet ?
• Last, i tried to fiddle with a plugins.render() function called from main renderer which in turn calls for all plugin's exposed render function, returning a react element class. The trouble is to integrate jsx in the plugin code (not a problem but for the needed transpilation) ; or we can write plain js react, but it's a bit of a pain.

What's your thoughts about this ?

[olup]

Thinking aloud here, but if we need to allow plugins to render, and if they access the state, they should be able to extend it and modify it. I am finishing my plugin draft, and i am mutating the state object as is, to show hide my menu or hold on subtitles options url, etc... But i am not sure that touching the state object like that is very safe.

EDIT :
Actually having good success by babeling the plugin files to write my jsx, displaying menu on state change, downloading subs and so on. Two things are still missing :

1 - Importing any react component using refs (as is the case with material ui) breaks as i don't render my react inside a render function of a react component. Trying to find a solution.

2 - it would be so great if styles could be extended too. Inline jsx styles is okay but I miss the power of all the pseudo classes. But that is maybe not too important.

[codealchemist]

Can you push what you have so far to a new branch?
I need to start playing with this and think about rendering JSX and extending styles.

Thinking aloud too: We should probably be able to export components in the same way Material does, and then dynamically require and use those components in the views we want to extend.

Thanks!