Выпуск Qmmp 2.0.0

Этому clang для канпиляния случайно не требуется, как дедбифу ?

Картинка не прилагается чтоле?

Там clang нужен, собственно, из-за -fblocks, потому что оно удобно. Насколько я знаю, для GCC оно что-то там попиливается, но запилят-ли - ХЗ. Как запилят, возможно будет и снова GCC собирать.

Зумер дитектед. Скины у него от winamp.

для преобразования кодировок текстов вместо удалённой из Qt возможности задействована библиотека libiconv;

И ради чего такие жертвы?

зачем вообще нужны библиотеки, которые регулярно ломают api при переходе на новые мажорные версии?

Не, больше всего, хорошего и разного, это хорошо. Но в чём ключевое преимущество сабжа перед теми же DeaDBeeF или Audacious, кроме того, что он - не они? В чём киллер-фичи?

в чём ключевое преимущество

А оно должно обязательно быть?

А есть альтернативы?

Скины у него от winamp.

Фу-у-у

Какой без этого смысл разрабатывать приложение, которое умеет ровно всё то же, что и несколько других, и умеет не лучше и не хуже?

Это ты про gtk?

Какой без этого смысл разрабатывать приложение, которое умеет ровно всё то же, что и несколько других, и умеет не лучше и не хуже?

это смешной вопрос, учитывая тот факт что дедбиф намного моложе

И ради чего такие жертвы?

Из-за винды и кодировки Win-1251 в тегах.

Лучше, конечно, ломать API в минорных версиях.

для преобразования кодировок текстов вместо удалённой из Qt возможности задействована библиотека libiconv;

О чём речь? Вроде на месте https://doc.qt.io/qt-6/qstringconverter.html

И ради чего такие жертвы?

Ради того, что вопреки представлениям эльфов из Qt Project, локальные кодировки в файлах у пользователей никуда не делись.

Я как-то приводил пример, мне несколько месяцев назад пользователь моего проекта присылал vcf-файл, только что экспортированый из MS Outlook. И там 1251 во все поля. Хотя в последних RFC на vCard ясно написано: The charset (see [RFC3536] for internationalization terminology) for vCard is UTF-8 as defined in [RFC3629]. There is no way to override this. It is invalid to specify a value other than «UTF-8» in the «charset» MIME parameter. Подчеркну: это не пользователь такой файл сделал, это программа такое прописала, не спрося его.

С аудиофайлами, как я понимаю, ситуация аналогичная: полным-полно материала с трекеров и др., где теги прописаны в локальных кодировках. Адекватные разработчики в такой ситуации добавляют костыли для поддержки реальной жизни, эльфы — начинают учить пользователей, в каких кодировках им сохранять строки. В условиях, когда подавляющее большинство пользователей сидит на винде, где всё и так работает нормально, и о кодировках вообще не думают, это просто ещё один повод для сомневающихся свалить с линукса.

Вроде на месте

Нихрена не на месте, оно только с вариациями юникода работать умеет.

Классический QTextCodec пока переехал в модуль совместимости и в перспективе, видимо, будет удалён. Хотя можно было бы его переместить в какой-нибудь отдельный QtTextEncoding, кому не нужно — может не подключать. Я бы даже согласился, чтобы его не включали в LGPL-редакцию Qt, а оставили только в GPL и коммерческой. Для свободных проектов вполне подходящее было бы решение.

Да, подключение iconv при сборке с Qt6 решает проблему, но это лишний геморрой для разработчиков. Особенно для платформ, отличных от линукса, где iconv придётся тащить в комплекте со своей программой.

На офсайте есть вот такая картинка, например.

Winamp ничего нового. Ожидаемо

Ради того, что вопреки представлениям эльфов из Qt Project

Не эльфов, а троллей.

Разработчики clementine, например, эльфы.

Гоблины, хоббиты

Если бы.

Высшие создания, феи, боги

Умеет. Не хуже. Тебя ж родили и не жалуешься.

Какое интересное описание индусов.

10 лет назад была киллерфича - плавный/безразрывный переход между mp3 файлами, была иллюзия, что cd слушаешь. Как сейчас у сабжа/конкурентов - не знаю.

Скины у него от winamp.

Фу-у-у

Страшно представить, какая психотравма была нанесена при участии винампа...

Предположу, что травма имеет вид

Winamp, it really whips the llama’s ass. Baaaaaaaaaah

Хлестать ламу по заднице - у кого угодно травма будет.

Я как-то приводил пример, мне несколько месяцев назад пользователь моего проекта присылал vcf-файл, только что экспортированый из MS Outlook. И там 1251 во все поля. Хотя в последних RFC на vCard ясно написано

2.1, наверное? Разве это проблема? Есть несколько версий и она обязательно указывается, проблем с импортом быть не должно.

Нихрена не на месте, оно только с вариациями юникода работать умеет. Классический QTextCodec пока переехал в модуль совместимости

Теперь ясно, увидел там QStringConverter::System подумал - оно и имеется в виду.

он совместим со скинами Winamp, очень даже недурственная фича

Добро пожаловать в мир линукса и магии, О Эльберет.

Интересно, что мешало в pro файл добавить QT += core5compat и продолжать использовать QTextCodec. Надеюсь со временем в Qt одумаются и вернут QTextCodec, либо доработают QStringConverter до возможностей QTextCodec.

Qt одумаются

Не одумаются. И compat тащить из-за одного класса ну такое себе.

из-за -fblocks

Блоки (англ. blocks) — расширение языков программирования C, C++, Objective-C, не описанное в стандартах этих языков и созданное фирмой Apple.

Всё что нужно о них знать.

Не одумаются.

Откуда такая уверенность? Корпорасты будут переходить на Qt6, заметят это безобразие, вернут подпрыгивая.

И compat тащить из-за одного класса ну такое себе.

А тащить еще одну библиотеку (libiconv) это не так себе? Compat немного весит по сравнению с остальными модулями.

Откуда такая уверенность? Корпорасты будут переходить на Qt6, заметят это безобразие, вернут подпрыгивая.

Пока не заметили. К тому же она была удалена из других классов. Из того же QTextStream, например. Так что возвращать её довольно нетривиальная задача.

А тащить еще одну библиотеку (libiconv) это не так себе?

Какую ещё одну? Она часть glibc. Более того, QTextCodec может её использовать.

Ну, в общем-то, это замыкания в С-ях. Что ещё надо знать. Штука удобная и, как я понял, в GCC тоже над этим работают.

Ну Apple добавила их в clang. Как пишут, у Apple и для GCC есть, но в своё время передавать права в FSF им не упёрлось. Сейчас передавать не надо, но Apple уже нафиг не надо.

И да, куча builtin-ов в GCC, в таком случае не смущает? Как и nested functions (тоже GCC-изм), которые в общем-то тоже замыкания, но не такие?

Информация к размышлению: 2.1 — до сих пор (в 2021 году!) — чуть ли не самая популярная версия vCard, поскольку по неясным мне причинам приложение «Контакты» среднего массового андроидфона экспортирует в VCF именно её. Единственным исключением, побывавшим в моих руках, была Motorola Defy+ 2012 г.в. с Android 2. Там был vCard 3.0. (*) В то же время сайт гуглоконтактов экспортирует 4.0 (не ведает правая рука, что творит левая).

Какую версию декларировал Outlook в моём примере, я навскидку не скажу, если интересно — посмотрю вечером.

Есть несколько версий и она обязательно указывается, проблем с импортом быть не должно.

Проблема-то не в детекте версий. Более того, в том файле в большинстве тегов было честно написано, что CHARSET — 1251. Проблема в том, чтобы библиотеку перекодировки тащить.

(*) Я вот подумал, может это как-то связано с тем, что в те древние времена Моторола была официальным брендом Гугла? Бонус для своих? В таком случае надо бы посмотреть, какую версию пишут всякие Nexus/Pixel. Не имел с ними дела, к сожалению.

И да, куча builtin-ов в GCC, в таком случае не смущает?

Смущает. Это порочная практика, мешающая переносимости. Я конечно понимаю, что есть специфические задачи, где это ой как требуется, но в большинстве случаев надо придерживаться стандартам и не прибивать код гвоздями к определённому компилятору определённой версии. К тому же нестандартную конструкцию всегда можно обернуть ifdef-ми, раз уж никак вообще.

какая психотравма была нанесена при участии винампа…

Дело в том, что для своего времени винамп был неплох. Но сегодня растровые шкурки, это что-то… В сабже именно такие.

Ненужное гуано с совершенно диким интерфейсом. Deadbeef топчик.

К тому же нестандартную конструкцию всегда можно обернуть ifdef-ми, раз уж никак вообще.

(сорри за ответ на офтоп)

В случае с deadbeef, это не используется как «нестандартная конструкция», а используется как одна из ключевых возможностей языка для написания асинхронного/параллельного кода, в связке с libdispatch.

При использовании языка C – никаких вменяемых альтернатив просто нет. Особенно, если учитывать, что существенная часть разработки происходит в Xcode, который для libdispatch / blocks имеет очень хорошие возможности отладки.

Все это добро работает на всех поддерживаемых платформах, и всех разработчиков это устраивает, и вообще было воспринято с энтузиазмом.

Увы, возможность не входит в стандарт, и есть только в clang. Будем следить за событиями, может и в другие компиляторы добавят.

2OP: поздравления с релизом :)

ключевых возможностей языка

Возможности языка определены в ISO/IEC 9899:2011. Всё остальное только добавляет проблем.

Но сегодня растровые gtk и qt, если чо. Начинавшиеся как векторные.

В сабже это выглядит отвратительно. Шкуры, если не масштабировать, мелкие, если увеличить масштаб в два раза (есть такая фича), то они «размываются». Лучше использовать «классический» интерфейс.
Как по мне, в линукс нет плеера лучше DeadBeef, который предоставляет больше возможностей для кастомизации, а-ля фубар на минималках. Это если критерием служит настройка внешнего вида.

переход на библиотеку Qt6

Ждём теперь и KDE6.

Я тебя огорчу, но на hidpi-мониторах у двух популярных тулкитов столько проблем, что масштабирование кнопок на их фоне просто мелочь какая-то. Впрочем, любителям страдать не привыкать.