Да, без 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 её всё равно придётся рефакторить — так что это временный костыль, а не решение
Самый больной момент — это то, что XML и Compose вообще не дружат, нельзя просто взять и переписать код частично. Приходится каждый экран полностью переписывать, и если архитектура не отделяет логику от UI, то можно здорово напортачить и потратить кучу времени. Навигация в Compose тоже часто вызывает боль — там всё сложнее и запутаннее, чем в XML. И ещё куча мелких проблем с импортами, компонентами и багами в Material3, из-за которых иногда хочется вернуться к XML. В общем, переход — это не просто смена синтаксиса, а реальный ребилд экранов и переосмысление архитектуры, так что готовься к долгому и мучительному процессу
Да, без 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 её всё равно придётся рефакторить — так что это временный костыль, а не решение
Самый больной момент — это то, что XML и Compose вообще не дружат, нельзя просто взять и переписать код частично. Приходится каждый экран полностью переписывать, и если архитектура не отделяет логику от UI, то можно здорово напортачить и потратить кучу времени. Навигация в Compose тоже часто вызывает боль — там всё сложнее и запутаннее, чем в XML. И ещё куча мелких проблем с импортами, компонентами и багами в Material3, из-за которых иногда хочется вернуться к XML. В общем, переход — это не просто смена синтаксиса, а реальный ребилд экранов и переосмысление архитектуры, так что готовься к долгому и мучительному процессу