Future consideration ?

[kannagi0303]

I think the interface of stacher.io is a good reference. If need a batches of tasks in the future, Similar methods can be used :)

[bachig26]

looks good...but please consider the RAM usage because GUI always consumes RAM more than CLI.

[kannagi0303]

You are right, but according to my experience, the RAM usage is roughly smaller or close to the browser opening a single tab.

I think the vast majority of devices should run smoothly, and I should still focus on being user friendly :)

[bachig26]

you're correct i guess, because the electron or qt or something.

I hope to see the gui is much optimized and smooth.

[bachig26]

1. Also It would be great to consider in reducing GUI package size, as current versions have around 80MB. Less package size will be good.

2. possible faster, smooth animations and gui launch.

[kannagi0303]

I'm very sorry, in the current situation, it is difficult to reduce the size.
Although the most important part of the running logic is less than 2MB, I can also directly package it into a GUI of less than 2MB, but there are many reasons why I don't do this

A: About startup

1. Running a program requires many dependencies, unless your computer already has this environment, the program will not execute correctly
2. Not all computers have the same version and environment, I have integrated all the dependencies used by the library to ensure that most people can run it normally
3. Even if it's only 2MB, it still won't load faster because you just scatter it and it will still read the same amount of dependent packages from your computer
4. The most important thing is that Microsoft has not yet proposed to improve the trimming function to make it more streamlined

B: About smooth animation
The WPF development platform provided by Microsoft is a full-fledged framework. Compared with the traditional winform framework, it can provide more stability. Reasonable invocation of resources is the focus of smoothness, and it is not much related to the size of the program.
I have used a hundred times more complicated situations in other projects, and it does not make the animation slower or faster.
Differences in computer hardware may have an impact, please forgive me for not being able to explain the details (if you are interested, please refer to Microsoft's instructions on WPF)

[bachig26]

[kannagi0303]

Moved to Issues.

[SONGjiemo]

你好，我设计了一个新的UI界面。可以探讨一下

[kannagi0303]

感谢您花时间设计界面。
关于这种形式的UI，在Github上已经有相当接近的项目了，大多数下载工具也都制作成条列的方式。
但是主要在网络的世界搜寻了相当长的时间，依旧无法找到最符合我个人使用的设计，某种程度而言，
目前yt-dlp-gui设计是偏向我理想的样式进行设计。

目前yt-dlp-gui预设格式优先选择，是使用我个人的公式去做判断，当然也能让使用者透过Config去修改喜爱的优先选择项目，
最主要我想保留能列出尺寸、编码格式...等等资讯让用户去做选择的功能。
以Youtube提供的规格而言来举例，可能符合720p尺寸就有av1,h264,vp9,3gp...等等不同的编码。
外加还会有Video Only的可能性，而我的经验中并不是每个视频都会提供完整的编码，
可能无法下载到用户所选择的格式，
例如 视频vp9+音频opus，就只能封装成webm(或mkv)格式，虽然也可以强制封装成mp4，但那不是符合mp4的标准规范。
而在 播放列表(Playlist) 当中的视频，所有的格式也都不同，很难批次的去对应到您希望的 尺寸与格式

在下载的过程中，关系到yt-dlp过程中如果利用到ffmpeg或第三方(例如aria2)下载工具时，并不一定会提供 进度、速度、剩余时间，
所以无法每个资讯都在列表中呈现，或许要改变呈现方式

以目标而言，我期望的不是简化可选项目，而是更便利的操作让使用者能正确拿到(下载)期望的格式。
有几款不错工具我觉得就相当贴近您设计的想法，

• 4K Video Downloader
• 3D Youtube Downloader
• YTDLGUI

我比较希望我能想出融合 stacher.io 与目前 GUI 的方案，
而幸运的是，网络上还有很多能替代并且可以下载 Playlist 的工具，我可以有更多的时间去思考并收集使用者的意见。
我比较不倾向去实作其他工具已有的功能与特性，因为不需重造车轮，不过我会尝试融入您的想法，但也必须顾及其他使用者的想法，不敢保证会还符合您的期许，请多包含。

[msteer22]

I tried the tool to download music from youtube.... maybe a feature to consider is providing the option to not download a video at all as I am only interested in the audio files.

I could not test what the tool downloaded as it did not work for me but even in case I get a separate video and audio file it would be a waste to download the video just to delete it!