C# Plugin Add Raw HTML/JS

[bakes82 167]

Is there anyway to add just raw html for some complex styling of items?

[Luke 42077]

Hi, do you mean on your own screen?

[bakes82 167]

I mean from the c# plugin. In the old method you had to write html/js in the new method you guys have defined objects. I’m asking if there is a way to add an item like new raw/div and give it raw html/css/js.

[Luke 42077]

Hi, not exactly, no. @softworkzmay have some insight on your closest available option.

[softworkz 5066]

10 hours ago, bakes82 said:

I mean from the c# plugin. In the old method you had to write html/js in the new method you guys have defined objects. I’m asking if there is a way to add an item like new raw/div and give it raw html/css/js.

The only way that is possible is to mix and have both - pages like in older plugins and PluginUI pages. The Diagnostics Plugin does that: The settings are PluginUI but the "Current Sessions" page with transcoding pipeline visualization is html/js.

[bakes82 167]

7 hours ago, softworkz said:

The only way that is possible is to mix and have both - pages like in older plugins and PluginUI pages. The Diagnostics Plugin does that: The settings are PluginUI but the "Current Sessions" page with transcoding pipeline visualization is html/js.

Uhhh it’s 2025 can’t you just vibe code some enhancements? You don’t even need to write code anymore just tell Claude Code to do it.

[softworkz 5066]

A core goal of the PluginUI is to be agnostic of any UI client framework (like html/js). 

Few years ago I developed a proof-of-concept, rendering the PluginUI through WinForms. It was just for fun of course, but as soon as there's a case where we need non-html rendering, we're ready for that (including all plugins using it).

[bakes82 167]

Then why not allow people to extend the controls and then you don’t need to worry about it, if it doesn’t render on xx device oh well. Even button functionality per device will be different and implemented differently. Or you do like plex and rewrite most applications to one language ex react

[Luke 42077]

29 minutes ago, bakes82 said:

Then why not allow people to extend the controls and then you don’t need to worry about it, if it doesn’t render on xx device oh well. Even button functionality per device will be different and implemented differently. Or you do like plex and rewrite most applications to one language ex react

We already have that with the web based UI, however, it isn't built with this new SDK for plugins.

[softworkz 5066]

13 minutes ago, bakes82 said:

Then why not allow people to extend the controls and then you don’t need to worry about it, if it doesn’t render on xx device

We want high-quality plugins that are working well everywhere. From the past, we have learned that this doesn't work out when letting plugin developers do their own UI. To some extent is has also been our own fault as the core html/css has been constantly changing and made it hard to keep up.

We also want that plugins are durable and keep working, even when the plugin developer is no longer available. That has always been a big problem. We had to "adopt" some of those plugins in order to keep them working for all Emby users.
Also, many of the server plugins with html config do not work on TVs or mobile devices (when going to the server configuration in those clients) because they aren't made to display properly there. In turn, we are maintaining a white-list of plugins which are working in those clients.

So you can see that's all far from ideal. PluginUI is meant to remedy those problems. When there is a plugin done with PluginUI, then

• It is more likely that it gets admitted to the plugin catalog
  => because we know that the UI will still work in some years, even when the developer doesn't care about it anymore
• it is easy for us to white-list it for being shown on all clients, because with PluginUI, it is more or less granted that it will be fine - and in case when not, then it is on us to fix the PluginUI rendering on the device, not on the plugin developer
• We know it will also work in TV mode - it's a future goal to make the admin UI smoothely accessible via remote control - this doesn't work with most html/js plugins

That's the concept of the PluginUI.

You can still use html/js pages, but it's not the direction we're aiming at.

[VicMoore 754]

@softworkzSounds like you are asking developers using HTML/JS in plugins to switch to PluginUI.  Is this actually possible for Plugins that have visually complex presentations and interactions?  

Vic

[softworkz 5066]

14 hours ago, VicMoore said:

@softworkzSounds like you are asking developers using HTML/JS in plugins to switch to PluginUI.  Is this actually possible for Plugins that have visually complex presentations and interactions?  

No, that's the one area that is out of scope.

You need to consider that we are talking about configuration UI for server plugins.
We do not have a plugin system for user-facing UI (like it would show up in client apps and web UI. We only have server plugins and for those server plugins, often a UI is needed for configuration. PluginUI allows to do that in an easy way without needing developers to build html and js files just for doing the configuration.

PluginUI allows you to do exactly that and is able to cover like 95% of those cases. Since the introduction of it, there has been only a single case where I had to resort to html/js, being the "User Sessions" view of the Diagnostics Plugin (which visualizes the transcoding pipeline). In that case, a mix is used of PluginUI and htmljs for that single view.

"Visually Complex Presentations" are generally rare, because it's rarely worth the effort for something that is only ever visible to Emby Server administrators.

[VicMoore 754]

@softworkzI greatly appreciate your answer and I understand the great value of the PluginUi. As you know, I mostly like pushing the boundaries of what Emby plugins and the Emby API can do. MyTv is one example. I program only for the joy of doing so and try my best to give the credit and all of the source code to anyone.  My goto tools are always html, JS and C#, rather than the PluginUi. Perhaps a hybrid of the two would be a winner?  

MyTv is intended for server administrators, not everyday users. It's very visual and interactive and probably suffers all of the problems that you mentioned html/JS plugins have. This is why I have not added it to the catalog. Remember that I am just having fun, and I rely on you to let me know if I have gone into the weeds.

Vic