Suggestion to everyone else: learn the CLI. Then you can do things like me last night. My wife collected a list of classical music videos she wants to play to our kid, and all I did was:
youtube-dl -x --audio-format "mp3" --audio-quality 0 -o "%(title)s.%(ext)s" -a music.txt
mp3splt -r *.mp3
I do batch downloads like these rarely, roughly once a year (though I expect it to happen more frequently in the near future). Because of that, I had both of the above commands stored in my snippets.org file. It's something I strongly recommend: store off-used CLI calls in your notes/personal wiki. It beats reinventing the commands a year down the line, or even trying to remember what tools did you use for that off job.
To preempt comments saying CLI is too hard for regular people: no, it isn't; they can learn, especially if you make them interested by e.g. showing them how to do batch jobs. But for the sake of the resistant, maybe the author of this GUI will upgrade it with option for batch downloads and format selection.
 - https://digitalsuperpowers.com/ is a nice book I read and can recommend. No affiliation, just curiosity, because the author is a regular HNer.
> It's something I strongly recommend: store off-used CLI calls in your notes/personal wiki.
All of my bash commands from any terminal get piped into a separate, unified history file, copying some setup I read about in a blog a long time ago. It's an easy, dumb setup that just works. I've been using it for years without any performance problems, and if I ever get any, I can just archive the current text file and start over with a fresh one.
Having access to past commands is really handy and has saved my butt multiple times.
$(history 1) =~ ^\ *[0-9]+\ +([^\ ]+\ [^\ ]+)\ +(.*)$
if [ "$command_part" != "$PERSISTENT_HISTORY_LAST" ]
echo $date_part "|" "$command_part" >> ~/.persistent_history
# Stuff to do on PROMPT_COMMAND
HISTTIMEFORMAT="%d/%m/%y %T "
alias phgrep='cat ~/.persistent_history|grep --color'
alias hgrep='history|grep --color'
My instinct says that if you'd run into any problems, it would be with this line:
'omxplayer' '--blank' '--aspect-mode' 'stretch' <(youtube-dl -o - --audio-format m4a --recode-video mp4 'https://www.youtube.com/watch?v=MKNYsKwM6HI')
It all comes together when the regular person takes a little time to learn the following three truths:
* the output of any CLI command may be redirected to the input of any other CLI command
* the output template of 99% of commands give you structured, predictable JSON data/metadata on which to operate
* 99% of CLI commands have the same sane defaults and are required by the spec to have the same option syntax for flags
* CLI is CLI. Generating a random number in the CLI on OSX is just as safe as doing the same on OpenBSD, Raspbian, QNX, etc.
 Three because I'm starting from zero
(If you ever happen to grow the project to the point of offering different languages, drop me a line, and I'll give you Polish language translations.)
EDIT: Also consider auto-updates for your application; it would be best if it could update its youtube-dl dependency independently from the app itself. I don't like auto-updates too much (especially when they're forced), but as others point out, youtube-dl and YouTube are in a state of cold war; YouTube downloads tend to magically break every couple of weeks now, which requires users to update the youtube-dl script.
 - https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-tri...
Auto-update will definitely be a feature it's quite easy with the youtube-dl package I'm using.
It's something we could do better at bridging the gap between.
Tbh things like this, a gui front end for a terminal app seem the best way forward. I don't know why they aren't used a lot more in open source, it just seems to match up so much better to the open source model of a random person developing a project and no one taking over when that person loses interest. The front ends are the sexy bits where you get more churn but also more interest. The boring back end doesn't attract, but also doesn't need so much attention.
I suppose you could argue we do it at the library level, I still think there's room to do it at this level also.
For a lot of people this isn't true.
I think for web developers, making guis is fun (why this is done in electron). For a lot of non web developers, making the actual tool is the fun part. Having to then fiddle around with some gui feels less like programming and more like a chore.
Each have their pros and cons. I'd say what makes most sense is a library with frontends (CLI, TUI, GUI, (web)socket, etc)
In this case I wouldn't need a GUI with Electron. All I would need is a Firefox extension for youtube-dl (or the hypothetical library). Why keep reinventing wheel? Hence library.
One annoying thing with CLI is defaults. You might wanna set defaults (in CLI often used in an alias). So I end up managing a large alias list but what if I use more than 1 shell depending on machine? What if the machine does not use Git to sync such files?
No but you can script the underlying youtube-dl so with the gui front end you get the best of both worlds.
Re defaults, that isn't an inherent shortcoming of terminal apps. Theres no reason why 'youtube-dl url' shouldn't just do the 'right thing'. I agree it's a common problem though.
The error in your reasoning is that you assume the existence of a singular right thing. Software that attempts to just do the right thing tends to suffer from what I call Overly Clever Syndrome. I hate waiters or store clerks that second-guess my motivations. Why should I like software that does the same?
That said, `youtube-dl $url` will download the pointed-to video in the best available quality, so that's a pretty decent default.
Gui apps have defaults too, this isn't a problem unique to terminal apps. I'll go further and say GUI apps suffer more because they tend to design around a default and have many fewer non default options, in the name of being easy to use. Terminal apps on the other hand 'suffer' because they don't make enough assumptions about how it is to be used.
Suffer is very much in inverted commas though, sometimes you want to do that niche thing, and having something that makes no assumptions about how it will be used is great. On the other hand having to read a manpage for the simplest of things is not so great.
Elitism. A lot of people in tech have gigantic egos and believe they are better than everyone else because of their arcane knowledge, so they have no desire to see anything become more discoverable or easier to use.
It's not an ego issue - I doubt any tech worker is happy when dealing with non-discoverable software as a user. But connecting this experience to building your own software, and learning to design things to be discoverable by default (because in a typical job, if you don't do something right the first time, it probably won't ever be done right), is hard.
A) power users having different priorities to light users. That tool you use every day, you probably use keyboard short cuts, know all the flags. The tool you use once every 6 months, you probably scan the menus and check the man page. Open source tends to be focused more on the power users, mainly because its probably power users that made the thing to start with.
B) open source tends not to be a 'product'. There aren't focus groups and usability testers, the first releases are Alphas and Betas so tend to attract technically minded people that find their way around less discoverable interfaces.
Using it is like pulling up the manpage while typing out a command, but interactive. Once you're done formulating your command, it runs in your worksheet and you can modify it and re-run it if necessary, just like any other command.
A lot of my friends don't use youtube-dl for this exact reason. They end up messaging me, asking me to download files for them.
I have no desire to automate my interactions with my friends, especially for something that's easy enough for me to do and only takes a minute of my time.
One video per day is free - if you want extra "credits" pay for it on the website.
I thought higher number = higher quality but then I had a look at the manpage again...
But having them installing ffmpeg and python, manually copying some exe to a safe place, and adding that as a enviroment variable really cuts the interest off.
(Dunno which package managers are alright in Windows.)
This is how you get Chocolatey: https://chocolatey.org/install.
scoop install youtube-dl
Point to Ubuntu in the Microsoft Store. Python is preinstalled. You may need to install Python's package manager (I'm not sure does it come preinstalled) with "sudo apt install python3-pip". Install it from Python's package manager with "pip3 install youtube-dl".
You could technically skip Python's package manager by just doing "sudo apt install youtube-dl", but updates are slow there, and you really don't want slow updates with this tool ("pip3 install --upgrade youtube-dl"). I'd argue that three commands are way easier to explain than installing two binaries and clicking around far too many times, especially because youtube-dl needs to be updated on a regular basis in order to work properly.
"Execute these commands only once and then just type youtube-dl https://example.com. If something breaks, run this command to upgrade the script and retry." If the target audience is someone who you think will feel comfortable doing youtube-dl in a terminal, you may as well point them to the total of three other commands to set things up.
Yeah, that makes sense. Things have changed since last time I went through that pain.
Why do people who use Linux automatically think you cannot use scripts or there are no scripting languages on Windows?
However, I would say use Git and just sync your stuff to a public/private Gitlab/Github repo depending on your needs. That's how I organize most of my public configs.
When composing my comment, I wrote a couple words about Org mode, then realized it's off-topic and deleted them before submitting the comment. I fully intended to leave just "snippets file", but forgot to remove the ".org" part.