Replies: 2 comments 4 replies
-
|
I think the only really feasible answer to this is "sorry, no". It's basically impossible, and I can pretty confidently say that no client devs would implement this. Just through how all of the native clients build their UIs and make adjustments to them, they're all very different and implementing changes from the web UI, from just changing pictures to full blown layout changes, is a hilariously massive amount of work. Some examples, because I suspect it's hard to grasp exactly how much of an undertaking this is.
As you can see, they're all different languages and technology stacks with vastly different implementations. Even when multiple clients use XML as a templating engine, the template winds up looking so different that there's effectively no sharing of code that can happen. This means that everybody would have to build their own clean implementation of this and figure out how to make it work within the constraints of their specific platforms. Speaking as a client dev, trying to pull customizations from the web UI and have them change things in our native clients is pure nightmare fuel. I can probably go one step further and say that this flat out wouldn't ever be supported by our Kodi addons because I don't want to go through the mountain of work to implement it, and I really don't want the ongoing game of whack a mole that would maintaining it. There's already a sizable pile of folks that edit their web UI and break something and then need help (or forget they did it at all). I can only imagine how much that problem would grow if other clients would take those changes and apply them as well. In addition to that, on these more locked down platforms where the average person will have a harder time pulling logs it adds another order of complexity to debugging and finding where the problem actually is. |
Beta Was this translation helpful? Give feedback.
-
|
I see where you are going from. Thats why i thought to make it in a as much as possible generic way without specifying any client in particular. The idea is that anything can be supported but it would be up to the client to decide what they can/want to allow to modify, for the WebUI it might be as far as to allow custom scripts to be loaded and for the AndriodTV to just to allow to change an Image. The featureset would be different and i dont expect this to be an immediate push to change everything but more of an gradual extension point. If the jellycon play next dialog is currently hard to modify at runtime, then it is just not an good extension point but other things could be. The proposal would not prefer one client over another, if one client decides to allow XML/Json/Html/Xaml code as an extension, plugin devs can use it but if it does not and only preferes to allow for example image changes thats fine. I know what kind of pain and mountain of work that looks like and if the kodi client does not want to invest in it, thats fine too but maybe there will be others/plugin devs that want to in the future and start implementing small extension points. That is why i proposed client specific keys so a plugin dev can build support for as many clients as possible specifically. The idea is to invest in the future and to allow modifications in a more controllable way by both the plugin and the client. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think you do. It being modular doesn't change the fact that implementing it on a client side would be awful. Generic almost always makes things way, way harder. If something is purpose built, it only has to match one case. If it's generic, it needs far more options and validation to work for multiple cases. On the contrary, from a user perspective, being modular quite possibly makes it worse, because now instead of a flat "this isn't supported" it's "this is maybe partially supported". So now that nice cohesive theme or feature they've made in the web UI is only partially supported in clients and looks mismatched.
Alright, well let's walk through this example. You want to change an image. Now in the client instead of just having your template and passing in data and generating it, you've added in another round trip for an api call to check the server if you should display the normal picture or a different one. Then you get it back and it's a gigantic image and the device can't handle it. Or it's a format that the local device can't handle natively so displaying it makes it all pixelated. So now you add in processing time to scale/crop/whatever the image to fit where it should. Before you know it, you've added an extra second or more of processing time just to a single dialog window. All the hours of optimization and smoothing out the UX of clients erased because somebody wants to change an image. And changing an image is the easiest option available here. But ignoring that, let's go to a more "real world" example, which is the kind of thing I think you're driving at with this: intro skipper. This isn't a simple "change an image" change. This is a whole new window requiring custom buttons. This is a simple case, and fairly common in the realm of what kind of things people/plugins are modifying the web interface for. So we'll assume kodi or android tv, as those are xml and would the easiest to implement this in. And since this is a "generic" implementation that anybody can use for anything, your template now has to be fully variablized for:
Cool. You work through that big pile of work, now any plugins can make this client display any custom windows they want. Cool, smooth sailing ahead. How do you make it work?. These windows don't exist in a vacuum. They need code behind them. How could intro skipper work if the client doesn't know how to handle those api calls? How could jellyscrub work if the client doesn't know how to retrieve all those timestamped images? So now it's not just the ability to customize the interface, it's the ability to dynamically generate api calls and how to handle them, or changing playback code, or literally anything because again, this is generic. So your options are either dynamically generate backend code for those interfaces, or every client that wants to support this needs plugin specific code for each plugin they want to support, which basically throws the whole generic thing out the window. And since brightscript and java are compiled languages, this might just flat out be impossible at runtime. I'd also bet that if this becomes a sort of "well known" thing, it could complicate approvals for app stores because now our purpose built app can potentially be used for something else. These are just some of the things that I can think of right now off the top of my head. I'm sure once you start trying to implement something like this you'll find plenty more problems, some of which will be platform specific. This is an absolutely massive rabbit hole of a feature that imo would never "just work" in any sort of reliable way. |
Beta Was this translation helpful? Give feedback.
-
|
One alternative I considered in the past is a separate plugin system that only works for the web client. It sounds incredibly disjointed (server plugins and frontend plugins) but it's also the only way that really makes sense for the huge changes you're considering. You could technically choose any client and if you end up on jellyfin-vue or the recently announced react client there wouldn't need to be consensus, although it would help increase adoption. I'm not sure how many projects have successful frontend plugins though, so if anyone can link examples that would be a good place to start. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
Well we do already have web plugins... the only hurdle really is having a way of injecting them. I have no idea how you would ever make them functional in multiple clients though... even within the web space that sounds incredibly painful. 😅 On a bit of a tangent, I love how eager everyone is to replace "the logo" when there are well over 30 different variations of the logo that would need to be replaced to completely rebrand web alone... |
Beta Was this translation helpful? Give feedback.
-
|
That's my point though. They would only be functional in the web client, or whichever client ends up getting chosen. I know web currently has a few basic options for plugins, but it's definitely a far cry from the UI and UX changes required for JellyScrub and similar projects. |
Beta Was this translation helpful? Give feedback.
-
With my current PR jellyfin/jellyfin#9095 I tried to allow for WebUI client modifications but that does not seem to be working out. Therefor i would like to propose a system that would allow Plugins to provide client customizations in a much more cross compatible way. The idea is for the server to provide a system that can register keys and features that will be delivered to a client if it does implement this function, and the client to interpret them.
I propose a server system where a plugin can register a key on a service. The key can be optionally prefixed with a concrete moniker to only target on specific UI like this:
It is up to the ClientUI to provide and support such extension keys.
Beta Was this translation helpful? Give feedback.
All reactions