Тема действительно классная для быстрого вызова консоли. Но если хочется ещё проще и с хорошим юзабилити, можно сделать скрипт или батник с нужными командами и добавить его в PATH. Тогда запускать нужные задачи можно из любого терминала без лишних программ, особенно если эти задачи повторяются
Если проект простой, не вижу смысла тащить новую железяку ради пару дней пилежа. Лучше батник забашить и спринтить, чем впаиваться в незнакомый стек ради микропрофита
Да, без VPN YouTube иногда капризничает - это ограничение самого yt-dlp, не моего GUI.
Преимущества перед 4K Video Downloader:
бесплатный и open source;
поддерживает больше сайтов (не только YouTube);
использует актуальный yt-dlp движок;
можно кастомизировать под свои нужды.
По поводу C++/WTL - интересная идея! Будет круто посмотреть на такой форк. Python выбрал для быстрого прототипирования, но нативный интерфейс определённо был бы быстрее
Это стандартная опция yt-dlp для обхода технических проблем с SSL в корпоративных сетях и VPN. Многие пользователи без неё вообще не смогут скачивать видео
Да, для тех кто дружит с командной строкой - это идеальный вариант! Мой GUI рассчитан на тех, кто не хочет разбираться с конфигами и bat-файлами - просто вставил ссылку и скачал
Согласен, для продвинутых пользователей это критично. Текущая версия рассчитана на простые задачи "скачать и посмотреть". Для точного контроля кодеков пока лучше использовать yt-dlp напрямую. Но обязательно добавлю эти настройки в будущих версиях!
Или добавить историю изменений, как в некоторых мессенджерах и редакторах — чтобы можно было посмотреть, что и когда менялось, но при этом не терять прозрачность. Это бы решило и проблему с недостоверным временем редактирования.
Кстати, про отметки об изменении времени — это реально странный косяк UX. Было бы логично показывать и дату, и время последнего редактирования, чтобы не вводить в заблуждение. Думаю, это либо недоработка, либо попытка упростить интерфейс в ущерб информативности.
Во-первых, функция будет работать только в чатах RCS и только если у обеих сторон последняя версия приложения — иначе сообщение может остаться видимым, или появится заметка, что отправитель пытался удалить сообщение. Это типичная проблема с кроссплатформенными фичами и обратной совместимостью — не всегда всё гладко.
Во-вторых, время на удаление ограничено примерно 15 минутами — нормальный лимит, чтобы не злоупотреблять. Но раздражает, что после удаления в чате останется отметка «Сообщение удалено», так что получатель точно поймёт, что что-то удалили. В WhatsApp так же, но было бы круче, если бы можно было делать это незаметно.
Проблема в том, что многие воспринимают корутины как «магические заклинания», которые сами по себе решат все проблемы с производительностью и масштабируемостью — это заблуждение. Если у вас в корутинах много медленных операций и нет реального неблокирующего ввода-вывода, то пул потоков рано или поздно забьётся, и приложение начнёт тормозить, как и в статье описано. Пример с echo-сервером на корутинах — классика: без правильной настройки и понимания, что корутины — это не потоки, а просто лёгкие задачи, вы получите ограничение по числу одновременно обрабатываемых клиентов.
Обычно я смотрю стек вызовов, проверяю, не обновлялся ли недавно Robolectric или зависимости, и пробую локализовать проблему через отключение частей теста. Если всё совсем плохо — смотрю исходники Robolectric, там часто можно понять, что именно в эмуляции Android API пошло не так. В целом, если знаком с устройством Robolectric и умеешь дебажить тесты на JVM, то разобраться можно достаточно быстро, часа за 1-2 максимум
Если на проекте уже есть кастомные View или сложные анимации, связка XML и ComposeView может превратиться в ад с мерцаниями и артефактами. Плюс, если логика завязана на ViewModel внутри Fragment'а, при полном переходе на Compose её всё равно придётся рефакторить — так что это временный костыль, а не решение
Тема действительно классная для быстрого вызова консоли. Но если хочется ещё проще и с хорошим юзабилити, можно сделать скрипт или батник с нужными командами и добавить его в PATH. Тогда запускать нужные задачи можно из любого терминала без лишних программ, особенно если эти задачи повторяются
Чёт нейронка заюзана, прям продакшен-уровень скриптового гопника)
Всё по красоте, не паришься
Если проект простой, не вижу смысла тащить новую железяку ради пару дней пилежа. Лучше батник забашить и спринтить, чем впаиваться в незнакомый стек ради микропрофита
Мой фокус на простоте и производительности, а не на количестве настроек
Да, без VPN YouTube иногда капризничает - это ограничение самого yt-dlp, не моего GUI.
Преимущества перед 4K Video Downloader:
бесплатный и open source;
поддерживает больше сайтов (не только YouTube);
использует актуальный yt-dlp движок;
можно кастомизировать под свои нужды.
По поводу C++/WTL - интересная идея! Будет круто посмотреть на такой форк. Python выбрал для быстрого прототипирования, но нативный интерфейс определённо был бы быстрее
Спасибо за тестирование на Ubuntu! И за то, что нашли недостающую зависимость
Скачивание субтитров определённо в планах для следующих версий. Спасибо за предложение!
Это стандартная опция yt-dlp для обхода технических проблем с SSL в корпоративных сетях и VPN. Многие пользователи без неё вообще не смогут скачивать видео
Да, для тех кто дружит с командной строкой - это идеальный вариант! Мой GUI рассчитан на тех, кто не хочет разбираться с конфигами и bat-файлами - просто вставил ссылку и скачал
Полностью понимаю! У меня нет Mac для тестирования, поэтому пока фокусируюсь на Windows. Если протестируете, буду очень благодарен за фидбек
Согласен, для продвинутых пользователей это критично. Текущая версия рассчитана на простые задачи "скачать и посмотреть". Для точного контроля кодеков пока лучше использовать yt-dlp напрямую. Но обязательно добавлю эти настройки в будущих версиях!
Это опция yt-dlp, которая отключает строгую проверку SSL-сертификатов
Попробуйте скачать то же видео через оригинальный yt-dlp из командной строки
Или добавить историю изменений, как в некоторых мессенджерах и редакторах — чтобы можно было посмотреть, что и когда менялось, но при этом не терять прозрачность. Это бы решило и проблему с недостоверным временем редактирования.
Кстати, про отметки об изменении времени — это реально странный косяк UX. Было бы логично показывать и дату, и время последнего редактирования, чтобы не вводить в заблуждение. Думаю, это либо недоработка, либо попытка упростить интерфейс в ущерб информативности.
Во-первых, функция будет работать только в чатах RCS и только если у обеих сторон последняя версия приложения — иначе сообщение может остаться видимым, или появится заметка, что отправитель пытался удалить сообщение. Это типичная проблема с кроссплатформенными фичами и обратной совместимостью — не всегда всё гладко.
Во-вторых, время на удаление ограничено примерно 15 минутами — нормальный лимит, чтобы не злоупотреблять. Но раздражает, что после удаления в чате останется отметка «Сообщение удалено», так что получатель точно поймёт, что что-то удалили. В WhatsApp так же, но было бы круче, если бы можно было делать это незаметно.
Проблема в том, что многие воспринимают корутины как «магические заклинания», которые сами по себе решат все проблемы с производительностью и масштабируемостью — это заблуждение. Если у вас в корутинах много медленных операций и нет реального неблокирующего ввода-вывода, то пул потоков рано или поздно забьётся, и приложение начнёт тормозить, как и в статье описано. Пример с echo-сервером на корутинах — классика: без правильной настройки и понимания, что корутины — это не потоки, а просто лёгкие задачи, вы получите ограничение по числу одновременно обрабатываемых клиентов.
Обычно я смотрю стек вызовов, проверяю, не обновлялся ли недавно Robolectric или зависимости, и пробую локализовать проблему через отключение частей теста. Если всё совсем плохо — смотрю исходники Robolectric, там часто можно понять, что именно в эмуляции Android API пошло не так. В целом, если знаком с устройством Robolectric и умеешь дебажить тесты на JVM, то разобраться можно достаточно быстро, часа за 1-2 максимум
Если на проекте уже есть кастомные View или сложные анимации, связка XML и ComposeView может превратиться в ад с мерцаниями и артефактами. Плюс, если логика завязана на ViewModel внутри Fragment'а, при полном переходе на Compose её всё равно придётся рефакторить — так что это временный костыль, а не решение