Open LukeHagar opened 1 year ago
A UI for ytdl-sub would be the dream - I'd love to talk more about this. I'm primarily a backend developer and have virtually no UI experience, but would be happy to talk through/implement what a REST api could look like that the UI would interface with.
My first choice is almost always sveltekit, so the integration should be pretty simple as the backend routes can use standard node commands and functions.
On Sat, Apr 29, 2023 at 5:40 PM Jesse Bannon @.***> wrote:
A UI for ytdl-sub would be the dream - I'd love to talk more about this. I'm primarily a backend developer and have virtually no UI experience, but would be happy to talk through/implement what a REST api could look like that the UI would interface with.
— Reply to this email directly, view it on GitHub https://github.com/jmbannon/ytdl-sub/issues/600#issuecomment-1528888242, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLQECXCHGIHYPZJBJMRTQ3XDWKHDANCNFSM6AAAAAAXQIKHSE . You are receiving this because you authored the thread.Message ID: @.***>
Looks fancy. Do you have much experience with using ytdl-sub? One thing i've been going back and forth on with a theoretical UI is whether to just support a subset of ytdl-sub (i.e. have it be a glorified TV show downloader) or try full compatibility
I have t used it extensively no, but it seems to me like it would solve a lot of problems for me specifically around music playlists on YouTube, that and SoundCloud.
I saw we go full support
On Sat, Apr 29, 2023 at 6:14 PM Jesse Bannon @.***> wrote:
Looks fancy. Do you have much experience with using ytdl-sub? One thing i've been going back and forth on with a theoretical UI is whether to just support a subset of ytdl-sub (i.e. have it be a glorified TV show downloader) or try full compatibility
— Reply to this email directly, view it on GitHub https://github.com/jmbannon/ytdl-sub/issues/600#issuecomment-1528893376, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLQECVWNA675SOA65J6LZTXDWOGTANCNFSM6AAAAAAXQIKHSE . You are receiving this because you authored the thread.Message ID: @.***>
Music is definitely more involved in terms of getting your config files right. You should definitely play around with scraping SC + YT music playlists first (see the music_audio_config config and subscriptions example). That should give you a much better idea about what's needed to go full support
I'm down for a challenge :)
Here are some examples of other projects I spend time on: https://github.com/luke-hagar-sp https://github.com/LukeHagar
I went ahead and ripped a current favorite from Sound Cloud, this is EXACTLY the kind of tool I have needed in my life.
So here is what I am thinking, let me know your thoughts.
You have already done so much for a functional tool in python, and it works WELL,
I think our best first step here is a comprehensive subscription yaml builder, with some sensible default configurations, The configuration would be stored in a way that they could be editable, but then adding subs to the sub yaml is a pretty simple operation, with the option of populating extra yaml keys in the subscription preset.
I am a contributor of the Skeleton UI Library for Svelte, so that would be my choice for components, do you have any preferences on themes or colors for the default theme for the UI?
You are the UI expert and the one writing it so I will leave it to you! Personally I prefer darker themes for night-time viewing
Glad we are on the same page :)
On Sun, Apr 30, 2023 at 8:23 PM Jesse Bannon @.***> wrote:
You are the UI expert and the one writing it so I will leave it to you! Personally I prefer darker themes for night-time viewing
— Reply to this email directly, view it on GitHub https://github.com/jmbannon/ytdl-sub/issues/600#issuecomment-1529224377, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLQECVBBE4HCYOB3WDZ5SLXD4GAPANCNFSM6AAAAAAXQIKHSE . You are receiving this because you authored the thread.Message ID: @.***>
@jmbannon From a logistical standpoint what do you think is the best way to bring the front end and back end together? I think ideally it would be ONE docker container for deployment, so do you want to take a shot at a single repo? Let me know your thoughts
Agreed it should be one container, but probably a new container to leave the existing one as is. As for the backend, I think the rest API could have its own layer that interfaces with the CLI ytdl-sub. All of this can live in the same repo, but in separate dirs (src/ytdl_sub, src/rest, src/ui).
This will require some extra plumbing to/from backend to rest, but I think will be for the best to keep ytdl-sub as CLI tool, build discord bots/etc from the rest API, and have its own home-grown frontend without each flavor stepping on each other's toes
I love that idea, so just to be clear, the front end would actually be interacting with an actual "always running" rest server? that makes things much easier for me
Does that mean that I should look to handle the configuration and subscription management on my end? so that the calls can be formulated and then sent to the backend on some kind of schedule?
Yes, the front end can assume a rest server (probably flask) is always running.
Config/sub management will need to be handled at the rest level. I think we should try to use files for storing state that can be shared with the CLI tool (we do this using the download archive file now). Any other state that the UI needs but not CLI can probably reside in sqlite
Do you use a discord server or anything for conversations on stuff like this?
If you don't have one I have one we could use
@LukeHagar join discord, I want to hop on this conversation too. It's something I've been thinking about alot too. Also glad to see someone using the unraid template!
@LukeHagar see the discord badge on the repo
@LukeHagar just updating this, and I am starting to get around to this. I am currently working on the first step. Which is making the configuration with more presets and ability to !include other files.
So this way, the "Simple" option would have only one config and one sub yaml.
!include tv_shows_config.yaml !include tv_shows_subscription.yaml
Or it could start off still living in one master config. We think this allows for simplicity, and easier YAML Building, but also will not break any existing configs at all.
Any suggestions on a YAML builder?
Any update on this? Would be willing to help test including functional and ux testing.
@jmbannon Would you be open to me assisting with a front end component to the amazing tool you have built here?
I would love to use this in my homelab on an unraid host, but I’m not very fond of making all the changes via yaml edits.
I have a fair amount of development experience and I would love to help out here