LINUX.ORG.RU

Выпуск Qmmp 2.0.0

 , ,


0

1

Доступен релиз плеера Qmmp, в котором осуществлён переход на библиотеку Qt6. Функционально данная версия аналогична вышедшей ранее 1.5, но обладает рядом особенностей, среди которых можно отметить следующие:

  • для преобразования кодировок текстов вместо удалённой из Qt возможности задействована библиотека libiconv;
  • временно исключены из сборки модули taskbar и qtmultimedia (до появления соответствующих возможностей в Qt6);
  • в некоторых модулях плеера используются внутренние интерфейсы Qt (до появления нужных публичных API);
  • проведена чистка кода от поддержки старых версий используемых библиотек.

Следует также отметить, что версии для Qt5 будут выходить параллельно до полного перехода основных пользовательских окружений на Qt6.

>>> Подробности

anonymous

Проверено: Harald ()

Ответ на: комментарий от anonymous

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

SkyMaverick ★★★ ()
Ответ на: комментарий от IRASoldier

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Ради того, что вопреки представлениям эльфов из 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. Подчеркну: это не пользователь такой файл сделал, это программа такое прописала, не спрося его.

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

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

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

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от IRASoldier

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

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от hobbit

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

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

anonymous ()
Ответ на: комментарий от hobbit

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

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

SkyMaverick ★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

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

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от SkyMaverick

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

waker ★★★★★ ()
Ответ на: комментарий от Shadow

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()