Компания Qt Company опубликовала релиз ветки Qt 6, которая включает значительные архитектурные изменения. Для сборки Qt 6 по умолчанию задействован Cmake, а в коде разрешено использование стандарта C++17. В новой версии заявлена поддержка платформ Windows 10, macOS 10.14+, Linux (Ubuntu 20.04+, CentOS 8.1+, OpenSuSE 15.1+), iOS 13+ и Android (API 23+). Достижение паритета с Qt 5 в поддержке real-time систем ожидается в выпуске Qt 6.2...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54218
Кто уже попробовал новый QML? Это все правда что там написано?
Да, все вроде работает, кстати старый код qml тоже работает
> Это все правда что там написано?Вроде бы нет. Компилиция в С++ и типизация например вроде должна быть только в Qt 6.1.
эмм. компиляция qml в С++ уже сейчас есть (5.12).
Просто в Qt6 ее довели до ума, убрали js, и типизацию сделали строже, а так то она давно есть.
>эмм. компиляция qml в С++ уже сейчас естьОх уж эти сказочники...
The Qt Quick Compiler is a development add-on for Qt Quick applications which allows you to compile QML source code into the final binary. When you use this add-on, the application's startup time is significantly improved and you no longer need to deploy .qml files together with the application. https://doc.qt.io/QtQuickCompiler/index.html
Где тут c++?
> компиляция qml в С++ уже сейчас есть (5.12)А код вы привести можете? Подсказка qml compiler это на самом деле совсем не компилятор в Qt 5.x.
Плюс для компиляции, а вернее транспиляции в C++ да так еще
чтобы все этого не тормозило на "embedded" QML должен быть статически типизированным.
И конечно до этого еще очень далеко.
Qt сила! GTK - могила.
В могилу они себя сами загоняют, что характерно.
Ути-пути!
> Qt сила! GTK - могила.Собственный тулкит поверх X11 - стронк! http://azsky2.html.xdomain.jp/soft/index.html
X11 must die!
Есть поддержка как X11, так и Wayland - http://azsky2.html.xdomain.jp/about_mlk.html
Это как сравнивать диван с многоквартирным домом.GTK это тулкит для рисования окошек, а Qt это огромный фреймворк в котором есть всё от SQL до 3D.
А если мне только тулкит и нужен? Не тащить же остальное г...о
Можно и не тащить. Используй только QML.
> А если мне только тулкит и нужен?Бери mlk (X11/Wayland) - http://azsky2.html.xdomain.jp/about_mlk.html
Демо (лицензия MIT) - https://gitlab.com/azelpg/mlkstyle
а если я не хочу тащить ни иксы ни вяленого?у меня, например, QML/Qt приложуха крутится поверх GLes с прямой отрисовкой в framebuffer.
без всяких лишних прослоек
> QML/Qt поверх GLes с отрисовкой в framebufferНашёл чем удивить.
Qt - медленное раздутое капризное дерьмо.Расходимся.
> Qt - медленное раздутое капризное дерьмо.
> Расходимся.с чем расходитесь, с трезвым рассудком? успехов.
Что это мне дает кроме того что опять все сломают?
А ты программист?
За маской Гая Фокса может скрываться кто угодно...
Но по статистике чаще всего оказывается школьник
... из Гонконга.
> ... из Гонконга.Во как, чего только в кивевской области нету..
Нет, поэтому и интересуюсь.
возможность публично поныть в комментария на опенете, чем тебе не возможность?
Ничего. Из описания не понял может ли оно работать лучше/быстрее кути 5 или просто фичами для разработки обросло.
наврено кеды начнут пилить новые через год, через два все сломают, через 3 решат, что все уже работает и можно в лтс пихать, через пять все заработает, через 6 появится кути 7
Ждём KDE 6
А там все в порядке с лицензиями?
В KDE всё в порядке с лицензиями.
https://www.opennet.me/opennews/art.shtml?num=52698
> Текущий договор между KDE Free Qt Foundation и Qt Company также обязывает публиковать все изменения в Qt под открытой лицензией, но допускает задержку публикации в 12 месяцев, чем и намерена воспользоваться компания Qt Company для повышения своих доходов.
> чем и намерена воспользоваться компания Qt Company для повышения своих доходов
> Ждём KDE 6Эх, а ведь раньше такое времечко-то было. Уже не будет никаких
> KDE 6.0 != KDE 6
> Android compatibility layer на всех виджетах kirigami для всех систем НЕ ПАДАЕТ!
> Дерни за KQMLCachew2.0 - плазма и упадёт. Скука!
> Возможность компиляции QML в представление на C++ и машинный код.а раньше в машинный код не было возможности с Qt Quick Compiler?
> Отказ от версионирования в QML.
> Унификация структур данных, дублирующихся в QObject и QML (позволит сократить потребление памяти и ускорить запуск).джва года ждал. на самом деле
да и вообще отличная новость же (но в проде, конечно, посижу ещё на LTS)
> а раньше в машинный код не было возможности с Qt Quick Compiler?Там вроде не машинный код. ИМХО просто убрана стадия парсинга, а так это почти тот же QML.
а ну да, в доке сказано что компилится QML компилится не в бинарный код, а "QML source code into the final binary" - просто встраивается как скомпиленный ресурс в выходной бинарник, а дальше там внутритрях вся та же механика парсинга QML и JS в рантайме.
Раньше в машинный код можно было только в коммерческой версии.
только было это настолько раньше, что аж в первых версиях Qt5
Нет, раньше Qt Quick Compiler всего лишь генерировал байткод для виртуальной машины. По сути только лишь слегка ускорял запуск приложения за счет того что парсинг и генерирование байткода происходила не в момент запуска приложения, а во время его сборки.Ну и то что планировалось компилировать в С++ и нейтив, этого еще нет.
надо было на rust писать аналог qt sdk, только с учётом ошибок, проблем, опыта
Пиши
И навертеть ещё больше метаобъектного кода, т.к. в Rust с объектностью не айс.
Ну не, это объективно глупо. Проект такого уровня переписать на другой язык в разумные сроки и бюджет просто невозможно. Это хуже, чем Gimp перенести на Qt :)
А вот официальный биндинг было бы неплохо увидеть. Что-то в эту сторону: https://www.youtube.com/watch?v=6pcOhCWLd_U
В топку Rust
Сколько проектов на нем сделал и что конкретно не понравилось?
Сколько г.на съел и что конкретно не понравилось ?
Но при чем тут Раст? Он же потрясающий.
На основе чего ты сделал вывод, что раст - говно?
Все его хейтят, но аргументации от хейтеров пока не слышно.
На rust невозможно написать ничего сложнее hello world. Мурзилла 15 лет пилила браузер и за это время не смогла ничего сделать.
> На rust невозможно написать ничего сложнее hello worldС чего вдруг? Ты пробовал? На нем можно написать абсолютно что угодно.
> Мурзилла 15 лет пилила браузер и за это время не смогла ничего сделать.
Эээ, что?
Они много чего сделали. Новые модули на Расте.
Ни одного завершённого проекта в мире. Мозила уже 15 лет пилит-пилит - всё переписать не может.
Еще одна статистика из воздуха, как же я вас всех люблю, опеннет :)
> что конкретно не понравилось?* Отсутсвие документации. Пойти и купить вон ту книгу - это не документация.
* Самобан веб сайтов относящихся к хрусту с его каргой сделавших недоступным его через эти ваши интернеты.
* Более гигабайта исходников и неожиданно невозможность собрать сие поделие на платформах отличных от линукс/виндовс x64.
* Блобы, блобы, блобы
* Отталкивает бесконечное кол-во идиотов окружающих сей инструмент - репутация.
Про сам язык я молчу, это список только того что мешает нормальным людям его просто установить.
> * Более гигабайта исходников и неожиданно невозможность собрать сие поделие на платформах отличных от линукс/виндовс x64.Но ведь Tier 1 (максимальная) поддержка есть также у 32 битных систем, а Tier 2 (которая не особо уступает) у больше сотни разных платформ. Если конечно нужно именно собрать, а не запустить на заданной платформе, то тут поддерживаемых платформ поменьше, но я не понимаю зачем что-то собирать на всяких странных платформах, когда кросс-компиляция делается несколькими аргументами в командной строке.
> * Блобы, блобы, блобы
Де блобы то? Нема блобов.
Специально для тех кто застрял в развитии на втором годике - отрицание проблемы не решает проблемы
> Отсутсвие документации.У Раста хорошая документация. Вполне на одном уровне с Qt, местами даже получше пожалуй.
Например, https://doc.rust-lang.org/std/string/struct.String.html
Если это = отсутствие документации, то я даже боюсь представить, что такое тогда "присутствие")> Пойти и купить вон ту книгу - это не документация.
Что купить? Какую книгу? Зачем?
> Самобан веб сайтов относящихся к хрусту с его каргой сделавших недоступным его через эти ваши интернеты
Какой самобан, о чем речь?
> Более гигабайта исходников и неожиданно невозможность собрать сие поделие на платформах отличных от линукс/виндовс x64
Например? В rustup Windows x32 есть. `rustup target add i686-pc-windows-msvc или gnu`
Андроид, арм линукс, мак интел, мак арм, айос арм, айос x86, всё это есть, и куча всего помимо.
Вручную собирать не надо, это не стоит того, через rustup (_официальный_ установщик) всё ставится и обновляется очень быстро.
Qt тоже желательно ставить инсталлятором даже на линуксе.> Блобы, блобы, блобы
Уточни?
> Отталкивает бесконечное кол-во идиотов окружающих сей инструмент - репутация.
А где они такие? На опеннете я наблюдаю скорее диких фанатов-сишников, орущих "раст гoмно" без адекватных причин. Кстати, спасибо за хоть какую-то попытку расписать причины, другие и этого не делают.
> Про сам язык я молчу, это список только того что мешает нормальным людям его просто установить.
А что язык? Не вижу ничего из списка, что могло бы реально помешать использованию.
> Не вижу ничегоПоследний пункт жирной линией подчеркивает какбе
Очень круто, надеюсь в Qt 7 запилят поддержку Раста
К тому времени про раст все забудут.
> К тому времени про раст все забудут.К тому времени LaTeX уже будет на расте - https://news.ycombinator.com/item?id=25328874
> К тому времени LaTeX уже будет на растеСразу после браузера. Ну и потом можно начинать писать документацию для хруста.
Спорим, что с каждым годом он будет лишь популярнее и привлекательнее?
Если уж даже сейчас после него C++ в целом как-то ну не очень. (говорю как c++ dev)
вот это да.
с какой стати Qt должен пилить поддержку Раста,а не наоброт?
С чего бы вдруг создатели _языка_ должны пилить поддержку какого-то фреймворка, при чем коммерческого?
Может, официальные биндинги Qt для Питона должен был лично Гвидо лепить?
ну кому нужно, вероятно, тот и должен пилить.PyQt разработан британской компанией Riverbank Computing (выдержка из педивикии), а не The Qt Company.
если Qt нужен кому-то на расте, то как бы растолюбы и должны были бы это сделать, не?
... который GPLный. Поэтому Qt Company запилила совместимый с ним пермиссивный PySide. Использовать следует его.
этот тезис "про следует использвоать его" актуален только для коммерческой лицензии (тк в опенсорц многие компонеты Qt тоже под GPL)ну, вероятно, когда:
1) rust наберёт такую же аудиторию как и python
2) а потом появится проект rust-Qt большой аудиторией (при чём коммерческими лицензиями), как это было в PyQtвот тогда может быть The Qt Company и примет на себя обязательства и издержки по официальным биндингам и поддержке раста (хотя даже для PySide это была не их проблема, но чтобы не потерять действующих коммерческих клиентов и разрулить ситуацию с лицензиями, они это сделали)
Однако он глючный, поэтому лучше всё таки PyQt.
PyQt — это другое. От разработчиков Qt есть PySide.> если Qt нужен кому-то на расте, то как бы растолюбы и должны были бы это сделать, не?
Биндиги да. И они есть. Официальную поддержку — нет (логично).
> PyQt — это другое. От разработчиков Qt есть PySide.
>> если Qt нужен кому-то на расте, то как бы растолюбы и должны были бы это сделать, не?
> Биндиги да. И они есть. Официальную поддержку — нет (логично).PySide появился только благодаря коммерческим клиентам Qt, которые хотели пользовать PyQt в своих проектах.
лепить как всегда будет тот, кому больше всех надо. Можно подумать, что официальные биндинги Qt для брейнфака должны существовать
Для брейнфака нет конечно, для Rust или C — why not?
есть же какие-то биндинги
например https://github.com/KDE/rust-qt-binding-generator
Годно. А растоманы пусть дальше мечтают.
- Отказ от версионирования в QML.
Мне кажется это породит много багов
ну, например, во многих других языках/тулкитах/платформах тоже не нужно явно указывать версию импортируемого модуля в коде прогрммы.
Например? А то куда ни гляну, везде версии хорошо если >=, а то и вовсе гвоздями прибиты
> Например? А то куда ни гляну, везде версии хорошо если >=, а
> то и вовсе гвоздями прибитыкак я уже сказал, имеется в виду явного указания версии при импорте в теле программы (как это сейчас происходит в QML), какая установлена, та и будет использована. Контролировать версию, видимо, нужно другими вещами (например во время компиляции).
* QML:
import <имя_моуля> <версия>* python:
import ... from ... - я не вижу явного указания версии в теле программы
* Nim:
from ... import ... - я не вижу явного указания версии в теле программы
* C#:
using ...; - я не вижу явного указания версии в теле программы
* C/C++:
#include <...> - я не вижу явного указания версии в теле программы
и тд и тпесли я правильно понял суть вопроса
> python ... не вижу явногоimport gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk;)
ну я не гворил, что такой возможности в том же питоне нет
хотя пример и похож на какую-то ГТК-специфическую конструкцию, а не общее правило при написании ПО на питоне
Нет. Версионирование модулей в QML нафиг не нужно и мешает возможности собрать прогу с более старой версией Qt
Всё пацаны Qt5 устарел.
Ну пока условно нет. Более "настоящим" релизом будет 6.1
6.2, т.к. в нем появится QtMultimedia.
и WebEngine
> ПоявитсяДа какой же это релиз вообще, если там, вдруг, поисчезали компоненты.
Я о Qt 6.0
qt 6.0, не qt 6
>>Более "настоящим" релизом будет 6.1Шо, опять Qt6.0!=Qt6?
> Всё пацаны Qt5 устарел.хе....
да преспокойно софт на Qt4 строю.
Qt5 - тормозной.
В каком месте Qt 5 тормозной?
> В каком месте Qt 5 тормозной?скачал текстозавра, редактор такой. Построен на Qt 5.12
Зарядил туда Спектр от Лукьяненко, прокручиваю -тормозит.
N++ тем не менее крутит его без проблем.
Подозреваю, что это проблемы реализации самого редактора
ну-ка, ну-ка, кинь ссылочку на свой софт, посмотрим, что ты там настроил
> Qt5 - тормозной.Интересно каким образом qt6 стал быстрее если это просто инкрементальный, ежегодный релиз ? qt200000 - вообще на одной лампе будет летать по такой логике
> если это просто инкрементальныйдядя Петя, ты дурак?
Ну здорово. Молодцы.
Походя объявили свой Fusion нативным стилем на линуксе.
Fusion и в Qt5 был дефолт. О чём речь?
Написано: "мы умеем Fusion - значит поддерживаем нативный стиль линукса".
Если Qt не нативный Линукс, то что тогда нативный Линукс?
Qt в линукс нативный. Но нативный стиль в линуксе не дефолтный стиль кьюта, а тот стиль, который настроен.
qt5ct
Не гтк3, а значит уже непогано.
Свят-свят-свят! Как ты мог произнести имя этого копродемона всуе!
> Свят-свят-свят! Как ты мог произнести имя этого копродемона всуе!Так это же не демон.
Деrmodemon уже есть у сообщества, это системда. С помощью нее запускаются бесенята с междумордием на гтк3.
Деrmodemon уже есть у сообщества опеннет, это псевдонимус
И анонимус пропрок его
>> Расширена поддержка дополнительных языков, таких как PythonНормальный дезигнер? Разработка под мобилки?
Питон под мобилки?https://memepedia.ru/wp-content/uploads/2018/11/mozhno-nenad...
На мобилках и так все на жабе и жабаскрипте, хуже уже не будет.
> На мобилках и так все на жабе и жабаскрипте, хуже уже не
> будет.Обе жабы работают значительно быстрее Змеи (и CPython, и PyPy). Кроме тех случаев, когда Змей напрямую грузит функции из натива.
Но что ему делать на мобилках? Виджеты не поиспользуешь. На пару с QML лучше всё же C++. Qt в Питоне, на мой взгляд, скорее для аналитиков/математиков, которым быстренько надо склепать UI на десктопе.
какие проблемы?
дезигнер на qt не нужен
Класс, четко, умеете... могете!
> В Qt 6.2 будут предложены дополнительные модули:Гыгы, не успели на СМаку перетащить. Фуу такими быть.
Электрон всё?
Давно уже. Просто криокамера у некоторых протекла..
>Встроен унифицированный движок для тем оформления и стилей, позволяющий добиться внешнего вида приложений на базе Qt Widgets и Qt Quick, родного для разных мобильных и настольных платформ.Вот все критикуют ГТК+ за их частое ломание тем, но там хотя-бы без бубна можно их можно ставить.
Вот я накачал из kde look всяких тем, а дальше что? (у меня openbox) Какие-то непонятные .qtcurve файлы, куда их присобачивать то? Да и даже если умудрится поменять темы (внешними костылями) некоторые приложения упорно тащат свои темы и никак не заставить их использовать что-то другое.
KDE != Qt
А что в кедах есть ещё что-то?
> А что в кедах есть ещё что-то?У них там свои абстракции. Далеко не чистый Qt.
Наконец вышло аж две новости для настоящих "тру" программистов и экспертов с opennet-а! Про bash и Qt.JavaScript прекрасно работает на мобилках, JerryScript и куча других JS движков не дадут соврать. Иначе бы их разработку давно бы уже свернули. Они там что, на V8 движке исполняли JS?
Релиз - это замечательно, ну а где приложения-то на нём? Часы в KDE? Популярные приложения на "богомерзком" JS/Electron постоянно вижу и пользуюсь ими. Куча приложений на Gnome. Ни одного на KDE. Ни в Ubuntu, ни в Fedora.
Эх, дали слабину. Пропустили трехочковый WebAssembly. Через пару лет мы будем компилировать JS (AssemblyScript) в WebAssembly и запускать и писать на нём QT приложения.
Так это, сегодня миллиарды людей используют софт на куте каждый день. Например, все лаунчеры для игрушечек на кутях. Тащить хром в лаунчер? Ну такое, из разряда фантазий. Какое ещё ПО на мобилках? Там одна вебня и так, ни одной нормальной программы там нет. Гном не работает на венде, это значит что? Это значит его не существует.
А хотя там всё равно же хром, только покоцаный немного. В принципе, какая разница? У кутей (помимо того что это единственный приличный кроссплатформенный фреймворк) есть ещё и рынок автомагнитол, тоже неплохо.
Телега? Зум? Не, не слышал.
Принимается. Про Zoom нашёл.Единичные приложения есть. Но это исключения. У Qt всё более сужающаяся ниша. Магнитолы, автомобильные системы, и т.п.
Думаю и там его через пару лет заменят.
>Думаю и там его через пару лет заменят.Заменят чем? Электроном что ли? Не смеши.
Да даже не электроном, а подобием той оси, в которой есть только браузер
Возможно флаттером, у него юзербейз растет стремительно, поддержки декстопов нету, но она заявлена в альфе для всех трех платформ.
Надеюсь, что нет.
Если честно, после QML синтаксис флаттера с дартом напоминает определенный sort of shіt.
QML проигрывает в том плане, что если сделаеть некорректный вызов плюсовой функции из QML (например неверные аргументы), то ты не узнаешь ничего пока оно не попытается сработать, имхо это серьезный минус
Так с любым скриптовым языком, достаточно просто привыкнуть это дебажить, логи какие-то выводить в дебаг сборке и т.п.
Мелочь на самом-то деле.
> Надеюсь, что нет.
> Если честно, после QML синтаксис флаттера с дартом напоминает определенный sort of
> shіt.Подобное бывает.. когда к одному из сортов shit'а приедаешься.. другие кажутся ну совсем не оч
Кутевской кмл, кстати, тоже на того_еще любителя.. в т.ч в плане архитектуры
Ну скажем так. Я не могу сказать, что прямо в экстазе от реализации QML в Qt, можно было лучше.
Но идейно — это лучшее, что я видел для интерфейса. Да и для чего угодно можно адаптировать, где удобнее декларативно записать (а это больше, чем может показаться).
Популярные фреймворки на JS или Dart действительно сложно адекватно воспринимать, там заметно больше синтаксического мусора.
> Но идейно — это лучшее, что я видел для интерфейсаВы просто не видели JSX :)
Который работает и в вебе и, с небольшими изменениями, на мобильных ОС
Видел, там же сплошной HTML
Засилье тэгов HTML в _собственном_ диалекте! Неужели у них мозг настолько повернут на этих тэгах, что нельзя было как-то мягко от них избавиться?
Electron c WebAssembly. Для меня лично самая вдохновляющая технология. Я считаю за этим будущее. https://www.infoq.com/news/2019/11/wasm-nanoprocesses-securityFlutter.
Kotlin Multiplatform.
Java с Graal VM.
Rust c каким-нибудь новым UI фреймворком.
Про руст отличная шутка кстати.
Объективно Раст не до конца готов для UI, но через несколько лет многое изменится.
Однако встаёт вопрос, нужны ли в UI языки, которые для UI не предназначены (rust, c, c++, java, etc) и не подходят (js, dart, etc)
> Объективно Раст не до конца готов для UI, но через несколько лет
> многое изменится.
> Однако встаёт вопрос, нужны ли в UI языки, которые для UI не
> предназначены (rust, c, c++, java, etc) и не подходят (js, dart,
> etc)В UI нужна разметка, с некоторыми из которых тот же JS очень даже неплохо дружит
Полностью согласен
...а потом очередная грета заметит, что жабоскрипт греет миллиарды процессоров куда как больше (ну как заметит -- вдруг кто-то решит поизмываться и подсунет "серьёзную аналитику", которую при этом хрен опрокинешь, потому как фактаж)...Всё-таки не зря нижний слой "веб-разработчиков" назвали четверорукими :-(
Вы вообще современный web видели?
Сейчас frontend по сложности сопоставим с backend и становится всё сложнее и сложнее.В то время как в backend всё давно отдано на откуп cloud provider.
И состояния то они не хранят (stateless), и инфраструктуру не хостят, всё делают за них.
Запросы к БД уже давно не оптимизируют, масштабирование автоматическое тоже сделано за них. Пришёл json / ушёл json.
На этом фоне frontend просто вершина программирования. Там огромное количество состояний, переключателей, анимации, это всё надо поддерживать на куче устройство, на мобилках и тд и тп.
> Вы вообще современный web видели?нашел, у кого спрашивать, он последние лет 10 только баш-портянками и вахтерством на опеннете занимается, но мнение, разумеется, по всем вопросам имеет
а потом очередной дениска попов вылазит в интернет и задвигает свою онолитеку
> ну а где приложения-то на нём?Stellarium, например? Одна из лучших свободных программ вообще.
> JavaScript прекрасно работает на мобилкахARM Cortex A != Cortex M
> Куча приложений на Gnomeэт каких? Твикер вместо полноценной панели управления? Или тех, которые с одной кнопкой.
Cadence Virtuoso, а может и другие кеденсовские поделки.
Приложение от АМД для видях, которое radeon settings на qt, даже в Майкрософт onedrive qt используют
Когда Qt Company будет куплена Microsoft?
Когда она поплотнее займётся IoT и прочей встроенкой, в т.ч. автомобильной
Они таки убили неюникодные кодировки. Одной причиной использовать QString стало меньше. Притом, что файлы, использующие эти кодировки, у пользователей никуда не девались.Беда-печаль.
Покажите мне этих пользователей и я первым кину в них камнем.
В очередь.
Банковский софт продолжает CP 866 использовать например, от этого никуда не денешься.
Ну например, скачали вы с музтрекера какой-то раритет, у которого теги в 1251. Вы их перекодировать будете? Если да, то это значит либо уходить с раздачи (фу), либо держать две копии материала (дважды фу). Поэтому, например, авторы адекватных линуксовых аудиоплееров позволяют выбирать кодировку для тегов.Более близкий мне пример. Я тут в свободное время пилю потихоньку кутешный редактор контактов (ссылка на гитхаб у меня в профиле есть). И мне народ с 4PDA присылает VCF-ы с 1251 внутри, сделанные всякими вендоутилитами, которые вполне себе в ходу. Некоторые просто с битой кодировкой, а у некоторых внутри честно написано "CHARSET=CP1251"...
Да много ещё можно чего накопать.
Сохраняю cue в utf8, кидаю старый файл в скрытые чтобы не мешался в фм.
> Сохраняю cue в utf8, кидаю старый файл в скрытые чтобы не мешался в фм.Ну когда есть CUE, это ещё ничего. А бывает материал и в MP3 с ID3 тегами. Ну вот бывают такие раритеты, которые в lossless найти невозможно, обидно, но факт. И вот там либо дублировать всё, либо...
Большинство современных плееров типа тунцца (опеннет свихнулся со своей анальной цензурой) хранит все изменения тегов отдельно в соей базе. Вроде такое же и в линуксовых плеерах было, но на общесистемном уровне только в kde да? Чтобы теги можно было посмотреть в любой гуёвой программе потом.
> Поэтому, например, авторы адекватных линуксовых аудиоплееров позволяют выбирать кодировку для тегов.А как это противоречит внутреннему программному представлению тегов в виде utf8? Когда ты читаешь строку из внешнего источника, её надо валидировать и допилить до вида, в котором она будет отображаться. Lossy конвертация в utf8 здесь самый удачный вариант.
На эти тонкости можно забить в консоли, если твоя работа со строками сводится к работе с бинарными блобами, которые ты получил снаружи и as is выкинул наружу, слегка поменяв порядок. И то, если мы глянем на тот же ls, он склонен прятать разные жопные символы, и рисовать их вопросиками или ещё как. Но если ты пишешь графическое приложение, и особенно которое работает со строками в разных кодировках, то тебе по-любому надо строки приводить ко внутренней кодировке. И лучше это делать прям сразу, как только прочитал, тем более что там это хорошо объединяется с копированием из буфера чтения в кучу -- тебе надо взять и не просто скопировать, а сконвертать в процессе.
Ну ты сам подумай, вот есть у тебя плейлист, там куча треков у каждого свои теги. Прикинь теперь как было бы интересно, если бы эти теги были бы в разных кодировках. Это чё, с каждой строкой хранить метаинформацию о том, в какой она кодировке, и затем при каждой перерисовке окошка конвертировать этот тег в юникод, потому что шрифт у тебя юникодный? Тебе процессор-то не жалко?
Ну "при каждой перерисовке окошка" - это очевидный наброс, не буду комментировать.С _каждой_ строкой - не надо. Если мы говорим конкретно про аудиоплеер, то при работе с гетерогенной коллекцией достаточно запоминать кодировку для конкретного каталога (включая его подкаталоги). И то только для тех каталогов, где она отличается от дефолтной. При такой постановке вопроса процессор, конечно, нагружается, но по сравнению с нагрузкой на то же декодирование потока - это даже не копейки, это доли промилле какие-то.
Случай "куча треков россыпью с разными кодировкам в одном каталоге" я не рассматриваю, это случай отдельный. Тут как раз разовое перекодирование предпочтительнее (кстати, для такого перекодирования, ВНЕЗАПНО, тоже нужен инструментарий).
> Ну "при каждой перерисовке окошка" - это очевидный наброс, не буду комментировать.Нет, не наброс. Тебе придётся перекодировать все эти теги. Либо в момент, когда ты их читаешь с диска, либо в момент когда ты их рендеришь на экране, чтобы символы тягать из юникодного шрифта, либо где-нибудь в промежутке.
В момент рендеринга на экран перекодировать глупо, я вижу что ты это понимаешь. Но при этом, складывается впечатление, что момент чтения с диска и конвертации прочитанных байтовых массивов в String не кажется тебе удачным моментом для перекодирования. Если так, то в какой момент ты бы стал перекодировать?
> Случай "куча треков россыпью с разными кодировкам в одном каталоге" я не рассматриваю, это случай отдельный. Тут как раз разовое перекодирование предпочтительнее (кстати, для такого перекодирования, ВНЕЗАПНО, тоже нужен инструментарий).
Я не вижу разницы между этими случаями. Мне кажется, что ты говоришь о логике принятия решения о том, в какой кодировке какой файл, но это совершенно отдельная логика ведь -- может быть ты используешь эвристики, может быть хранишь базу уже встреченных файлов и в ней кодировку к каждому, может быть объединяешь и то и другое, чтобы сделать пользователю удобно эвристикой, но не прибивать его гвоздями к её несовершенствам и дать возможность вручную настроить. Может ты придумаешь что-то ещё. Это не важно. Важно то, что если ты хочешь рендерить теги, то как бы ты не принимал это решение, тебе придётся перекодировать в юникод.
На самом деле, я вот подумал, рендерить ведь мало, неплохо наверное ещё поиск по тегам иметь? А это значит, что неплохо было бы вообще собирать все теги со всех файлов в sqlite и хранить там. И хранить их там в юникоде. Не будешь же ты каждый раз при каждом поиске перебирать все файлы и вынимать из них теги? И хранить мешанину кодировок в sqlite не будешь: как ты там после этого искать будешь?
> Но при этом, складывается впечатление, что момент чтения с диска и конвертации прочитанных байтовых массивов в String не кажется тебе удачным моментом для перекодирования.Не знаю, откуда у тебя такое впечатление складывается. Если плеер основан на коллекции, лучший момент для перекодирования строк - сканирование папки с коллекцией. Если на файлах и плейлистах - загрузка каталога в плейлист.
> Важно то, что если ты хочешь рендерить теги, то как бы ты не принимал это решение, тебе придётся перекодировать в юникод.
Так, а я разве против? Я против того, чтобы менять сами медиафайлы, а база/индекс вполне может храниться в виде, приведённом к единой кодировке. Более того, должна.
И всё это никак не отменяет того, с чего я начинал. А как раз подтверждает: библиотека для перекодирования очень важна для прикладного софта. И чем хорошо наличие её в Qt - это реальная кроссплатформенность. В частности, в винде не надо трахаться с дополнительными зависимостями и прописыванием в проект абсолютных путей к внешним библиотекам.
В каком месте убили?QString provides fromLatin1(), fromUtf8(), and fromLocal8Bit(). Other encodings are supported through the QStringEncoder and QStringDecoder classes.
https://doc.qt.io/qt-6/qstring.html
А если мы немного попутешествуем оттуда по ссылкам, приходим к списку поддерживаемых кодировок:
https://doc.qt.io/qt-6/qstringconverter.html#Encoding-enum
Из неюникодного там только Latin1 и System.
Классический QTextCode поддерживал кучу кодировок, я мог взять файл в однобайтовой кодировке (совсем необязательно имевшей отношение к локальной кодировке МОЕЙ системы) и перевести его во что угодно.
Если подумать, а какой смысл в других кодировках? Это играет роль разве что для тех, кто делает свой блокнотик. В остальных случаях оно в целом и не надо.
Не спорю, что это иногда может быть нужно, но лично я использую везде юникод.
Интересно теперь, когда QTextCodec удалят из Qt 6.А в QString в любом случае остается смысл, пока в stl не появятся нормальные строки.
Ну например я для себя написал небольшую программу, которая автоматически обновляет прайс лист от нескольких производителей, но тянет информацию с web страниц этих производителей. У них прайса в другом виде нет, и даже нет общего прайса, а только каждая деталь на отдельной странице. Деталек тысячи, вручную накладно обновлять. Так вот, у некоторых производителей кодировка windows-1251, да и другие встречаются. В самой странице содержится информация о кодировке и программа автоматически преобразует в UTF8 при помощи QTextCodec, а дальше поиск специальной подстроки с ценой детали. Вот эта искомая подстрока иногда содержит кириллицу. Это пример зачем нужны другие кодировки.
> Если подумать, а какой смысл в других кодировках? Это играет роль разве что для тех, кто делает свой блокнотик.Я выше приводил пример - мне пользователи присылают файлы в cp1251 от сторонней программы. Я программу пишу, чтобы людям было удобно. А если я им буду говорить "да ваши кодировки вчерашний день, используйте юникод" (они ведь даже не сами кодировку выбирают, так чья-то программа написана!), на меня посмотрят, как на быдлана, и правильно сделают. И да, у меня далеко не блокнотик.
Аноним выше тоже дал пример из реальной жизни. Жизнь, она далеко не везде юникодная.
> но лично я использую везде юникод
И на здоровье! Но вот если вы пишете программу не только для себя и даже не для одного конкретного заказчика, а для более-менее широкого круга людей - можете столкнуться с очень разными ситуациями.
Повторюсь: не спорю, что это иногда может быть нужноПоэтому и предлагаю продолжить использование QTextCodec в Qt 6 из модуля совместимости, пускай и под GPL only.
Действительно непонятно зачем уменьшили количество поддерживаемых кодировок. Может еще одумаются. Благо возможность использовать QTextCode осталась, нужно только в в pro файле добавить QT += core5compat
*QTextCode
QTextCodec
> зачем уменьшили количество поддерживаемых кодировок.Просто политика. Заметь, Latin кодировку не убрали.
> Заметь, Latin кодировку не убрали.Ну это можно объяснить тем, что Latin - простейшее подмножество UTF8. Но да, на нехорошие мысли наводит.
Там уже название модуля намекает на то, что оно будет выброшено, вопрос - когда.
Одумаются ли - зависит от багрепортов, причём конечно, желательно, не от абы кого, а от бояр, покупающих коммерческую версию. :)
Кде 6 в 2021, интересно а вы, что думаете?
Ничего. До LTS ещё далеко. Весомых причин нет. Думать о том, чего нет, это избегание реальной жизни.
>Функциональность поддержки платформ, ранее предоставляемая модулями QtX11Extras, QtWinExtras и QtMacExtras, перенесена в специфичные платформозависимые API, доступные напрямую из Qt.Это только планируется в 6.1
Не знаю как кому, а по мне то что Windows 7 и 8 более не поддерживаются говорит о том что праздник не удался!
О чем речь, если сам разработчик этих ОС завершил их поддержку?
7 перестали поддерживать почти год назад, 8 - в 2016, 8.1 - в 2018
Чет не вижу где это сказано. Сказано только что W10 поддерживается, а что 7 дропнули - нет.
Почему в новостях про Qt так много слов 3D? На Qt игры пишут какие-то?
Маркетинг... Кутя давно скатилась.
В Кумысэль используют, наверное.
3D - это не только игры, внезапно. И направленность 3D в Qt явно далека от игр
так теперь можно будет и игры, в чем проблема?
Если бы Кармаку дали культю и только её, мы бы не увидели Doom.
Ромеро тогда уж.
таким как "вы" испраженинями можно лицо обмазать, вы ничего не то что не увидите, не унюхаете, не то что Doom
Пора начинать KDE переписывать с нуля
когда приступаешь?
надеюсь, оповестишь об этом грандиозном событии сообщество KDE
Завтра после обеда. Отпиши в сообщество сам, мне некогда, я пилю кде.
Бета-версия, по сути. Нет половины нужных модулей. Придется ждать 6.2, что поделать (мне нужны Multimedia, NFC, Remote Objects).
Релиз будет проприентарным.
> Qt Quick 3D Vulkan Metal Direct 3DВот был раньше один OpenGL, все писали на OpenGL, нафига было рожать этот зоопарк?!
Metal - это вроде как технология Apple (родная для Mac)Direct3D - это вроде как технология Microsoft (родная для Windows)
OpenGL - это вроде как кроссплатформенная открытая технология, так или иначе с какими-то ограничениями, по сравнению с родными для каждой платформы (может быть и незначительными), который сам всегда всё реализовывал и управлял миром на своей стороне
все три друг от друга не зависят (поэтому скорее всего и создавались, чтобы одна копрорация не зависела от другой в своих продуктах)
Vulkan - продолжение OpenGL, под капотом работает в том числе поверх родных Metal/DirectX.
к сожалению пока что ситуация такая да, от OpenGL спешат избавиться как от устаревшего, в то же время Vulkan ещё не везде может летать, как OpenGL летал.ну не такой уж и зоопарк, на самом деле
могло быть хуже
Metal - 2014, зачем эти поздние роды?!Direct3D - тут всё просто, был OpenGL и *nix, как M$ показать, что игры надо писать под венду? А давайте сделаем на венде убл@д*чную реализацию OpenGL, которую обгонит наш же DX, и все будут писать под DX, т.е. под венду!
Vulkan - это когда Кронос ударился головой в маркетинг. - А что, если развивать OpenGL? - Да ну нах, давайте заставим всех писать на несовместимом ни с чем ассемблере!
есть OpenGL и OpenGL для встроенных это две большие разници. Вулкан только называют продолжением, на самом деле он имеет совсем другие возможности обработки графики. И потом, зачем он нужен тем кто делает игры под Винды и Соньки. что касаемо мобильных игр. ну нет Mali-G72 в составе arm64 в сочетании с ядрами cortex-a. В конце концов я сам этим и занимаюсь, чего лукавить, да Вулкан поддерживает, но главный упор на экономичность. Обработка графики требует больших энергозатрат. Писать же коммерческие игры под Линукс не имеет смысла. Впрочем, вышел только что новый проц от Квалкомов - он мощный хоть и на cortex-a архитектуре от ARM. никаких х64. интел сдает позиции от мобильных и далее нетбуки, ноуты и так далее. пока вот...
Если я правильно понял, то Vulkan -- это ни разу не продолжение OpenGL, а скорее шаг назад, ближе к железу.
Direct3D — это ни разу не продолжение Direct3D, а скорее шаг назад, ближе к железу. Ну вот примерно одно.
Для сравнения скорее лучше "DirectX 12 — это ни разу не продолжение DirectX 11, а скорее шаг назад, ближе к железу"
да все нормально работает. у меня еще релиз кандидат был собран и под х86 и под arm64 практически вышедший релиз не отличается по коду
6.1 или 6.2 будет проприентарный - шас на хомячках оттестируют и закроют. Спасибо, ребяты!
Чиво? Это откуда такая инфа?
Так 6.0 уже должен быть закрытым, а раскрываться должны были версии через несколько месяцев/лет. Объявляли сами разрабы.
Кто то жопой читал новости
Даже в это статье напейсано -"Лицензионная политика и модель распространения фреймворка остались прежними, опасения, связанные с усилением коммерциализации проекта, не подтвердились."
Однако, от старых планов то не отказались официально, всегда висит угроза.
Имхо, КТ полуприетарная разработка, по сути.
>Windows 10
>7 нетМарионеточная компания Microsoft не палится.
Я не то, чтобы хочу сказать, что это хорошо. Это плохо.Но с другой стороны, никто не запрещает при необходимости тянуть сборки своих проектов на Qt5 до посинения. Вон, Qt4 поддерживалась много-много лет после выхода Qt5, и только в последние год-два начала выкидываться. Общественность даже не дала выкинуть Qt4 из Debian Buster, хотя поползновения были. При этом Qt4 и Qt5 обладали очень высокой степенью совместимости, если соблюдать аккуратность и не вляпываться в некоторые модули вроде QtWebEngine - можно иметь код, нормально собирающийся и работающий на обеих ветках.
Если с переходом Qt5->Qt6 будет так же, то для поддержки клиентов на Windows 7 достаточно делать сборки под Qt5, есть шанс, что с Windows 7 люди свалят сильно раньше, чем закончится поддержка Qt 5.
Поддержка Qt4 закончилась в 2015 году, 3-х лет, после выхода Qt5.
Ну по факту 2015 - это год выхода Qt 4.8.7, которую после этого основные дистрибутивы тянули ещё долго (в Debian Stable есть до сих пор, с патчами для OpenSSL от энтузиастов).
>есть шанс, что с Windows 7 люди свалят сильно раньше, чем закончится поддержка Qt 5.Понимаете в чём дело ... дело не в том, что Qt 5 не работает. Дело в том, что писать под legacy - не стильно, не модно, не смузихлёбно. Поэтому ради того, чтобы использовать 6, все подряд просто возьмут и выбросят 7 и 32-бита на помойку. Просто возьму и выбросят. Скажут "раз вы на 7 - значит вы не нужны. У вас денег даже на новый комп нет. Зачем нам такие нищeброды в клиентах? От вас денег меньше, чем гимора!". Одна компания так сделает, вторая так сделает, третья так сделает. И пользователи пойдут и купят новые компы. А куда деваться-то с подводной лодки? Да, неприятно, что какой-то ******к (я сам таким *****ком был, да и что греха таить, остаюсь, правда уже более в бесплатно-свободно-софтовом плане, в хардварном и проприетарно-софтовом стараюсь не диктовать, потому что апгрейд реально стоит денег, я считаю, что я не имею права от людей требовать занести кому-то денег, особенно тем, занесение кому денег этим людям повредит) просто берёт и диктует "вы купите новые компы по желанию моей левой пятки", а что поделать? У него *****ка софт, которым весь мир пользуется, и многомиллионная корпорация, а у тебя, такого хорошего, софта этого нет и не будет, а работу делать надо. Поэтому пойдут и купят. Загоняя очередной гвоздь в гроб семёрки. Чем меньше пользователей и чем они менее активно противодействуют, тем больше соблазн для остальных разрабов так сделать. И какая-то часть, пропорциональная соблазну, из них это сделает. Скажут "достало, вот *****ки, таки придётся новый комп купить". А когда купят, скажут "ура, конец мучениям с поддержкой старья, отмычался я, я почему старьё поддерживал - у меня у самого комп старый был. Да здравствует прогресс!", и выпилят всё legacy, попутно подняв системные требования.
Сколько лет будет поддержка Qt 5?
Два главных вопроса:
1. от moc наконец избавились?
2. сделали ли к QObject move конструктор?
Полагаю, что это не самые главные вопросы, а вот эти
1. Какие проблемы с moc?
2. Есть ли какая то необходимость оного?
Полагаю, ты никогда не видел других языков/фреймворков со свойствами и событиями здорового человека... ой, простите, человека без инвалидности. Тогда бы для тебя был вопрос:
1. В каком будуне придумали этот moc?!
Если бы ты знал зачем он, то и не спрашивал бы. Причём на Qt ты не пишешь, так ради чего лай?
Сам-то - знаешь? Или только сейчас увидел?
Да что ты такое несешь? Чтоб ты всю жизнь моргерштерна слушал!
moc файлы это лишняя каша и такой мусор при сборке. Тем более вообще не нужная ерись. По хорошему это все можно заменить на шаблоны. Мне по ходу работы приходится с приватными классами работать, и поверьте, если бы вместо этого г.. были бы шаблоны то писать было бы на много проще.
шаблоны не позволяют добиться той степени рефлексии, что с MOC
работал он. ты даже не понимаешь, для чего нужен moc, а уже целый параграф выс*ал, откуда вы лезете?
> от moc наконец избавились?Нет, конечно. Это же кутяшевцы.
> 1. от moc наконец избавились?нет, но для property-ей moc и event-loop теперь не нужен, всё на плюсах
Неудивительно, что от Qt отказываются, с такими-то закидонами...
Кто отказывается и с какими такими закидонами?
Я отказываюсь
> Я отказываюсьИ какие у тебя закидоны?
> И какие у тебя закидоны?Вот тааааакиииие
> собственный пакетный менеджер на базе проекта СonanНу конеееечно, использовать сам conan нельзя, в нем фатальный недостаток ага.
> Перевод полной поддержки JavaScript в разряд опций (использование полнофункционального JavaScript-движка требует больших ресурсов, что мешает применению QML на таком оборудовании, как микроконтроллеры).
Да лааадно а то сразу не понятно было.
> Уход от генерации структур данных во время выполнения в пользу генерации во время компиляции.
Да лаааадно а то сразу не понятно было что это уг.
> В качестве системы сборки использован инструментарий CMake вместо QMake.
Да ты чееее, а то сразу не понятно было что оно мертворожденное.
> Расширена поддержка дополнительных языков, таких как Python и WebAssembly.
Ну а кудаж без этого а то работать та там остались только вебмакаки и они же ныть будут если это не поддерживать.
Заглянули на огонёк. Обработка дат притягивает ошибки или 77 дефектов в Qt 6 - https://www.viva64.com/ru/b/0801/
