LINUX.ORG.RU

Сопровождением Qt 5.15 займётся проект KDE

 ,


1

1

После того, как Qt Company объявила о прекращении доступа к репозиторию с исходным кодом LTS-веток Qt, новые исправления в ветке 5.15 смогут получить только обладатели коммерческой лицензии. Публичный доступ к ранее опубликованному коду будет сохранён, но новые изменения и исправления будут оставаться закрытыми для сообщества. Исключениями являются только Qt WebEngine и объявленный устаревшим Qt Script, которые имеют внешние зависимости под лицензией LGPL.

Для поддержки ветки Qt 5 в актуальном состоянии до момента завершения миграции сообщества на версию Qt 6, проект KDE начал формирование собственной коллекции патчей Qt5PatchCollection, в которой они взяли на себя ответственность за сопровождение патчей к Qt 5.15, включающие в себя исправления ошибок и уязвимостей. Патчи доступны в виде Git-репозиториев под названиями, соответствующими определённым Qt-модулям.

На данный момент в репозитории включены только патчи, одобренные проектом Qt, но также рассматривается возможность внесения и неутвержденных ими патчей в будущем. KDE не планирует выпускать отдельные версии своего набора патчей, а будет развивать его как непрерывно пополняемую коллекцию, началом которой будет последняя версия общедоступного кода Qt 5.15.

Сроки поддержки пока не оговариваются. Известно лишь то, что планируется осуществлять поддержку до тех пор, пока у сообщества будет запрос на использование Qt 5.15, или пока Qt 6 полностью не заменит 5 версию в разработке свободного ПО.

>>> Сообщение о закрытиии Qt 5.15

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: commagray (всего исправлений: 4)
Ответ на: комментарий от EXL

WineLib и WinAPI – всегда стабильный API к вашим услугам и в Linux.

Забавно, конечно. Есть какие-то примеры чисто Linux'ового ПО, которое его использует? Наверное он не очень удобен в современных реалиях. Привязок к разным языкам нет, устаревшая архитектура. Даже Microsoft пытается его заменить или надстроить.

ls-h ★★★★★
()
Ответ на: комментарий от ls-h

Привязок к разным языкам нет

Пфф, там же чистый Си, привязать можно к чему угодно.

Даже Microsoft пытается его заменить или надстроить.

Ага, начиная где-то с Висты. Только грамотные менеджеры всякий раз заменятелей осаживают.

Меня помимо прочего, забавляет, что под вайном я могу Shift+Ins использовать с обеими клавишами Ins, как на нумпаде, так и с традиционной. И со стрелками так же. Между тем, в нативных линуксовых приложениях такое поведение хрен настроишь (т.е. какие-то инструкции попадаются, но оказываются устаревшими либо неработающими).

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

Насчёт GTK, я, возможно, погорячился. Не знаю насчёт совместимости, но gtk2 хотя бы есть в репозиториях и софт на нём продолжает работать. А Qt4 уже давно выкинули и Qt5 ждёт та же судьба. Воспринимаю намеренное убивание Qt5 как диверсию против всего СПО, ведь часть софта опять пропадёт, а остальные будут вынуждены тратить усилия на переход.

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

А Qt4 уже давно выкинули

4.2, в Fedora 33 работает, в Debian Buster тоже. В Manjaro выкинули совсем недавно, ещё пару месяцев назад всё собиралось. И это спустя много лет после выхода Qt 5.0.

намеренное убивание Qt5

Да кто ж его убивает? Наоборот, в свете последних событий на пятёрке будут сидеть до посинения.

часть софта опять пропадёт, а остальные будут вынуждены тратить усилия на переход.

Последняя глобальная ломка в Qt была при переходе с 3 на 4 ветку. У меня полно кода, работающего в Qt4 и Qt5 с МИНИМУМОМ условных компиляций (к примеру, я так и не понял, нафига было выносить StandardPath из QDesktopServices, ну да ладно). Не повезло тем, кто в Qt4 был завязан на QtWebKit, это да (и то для них есть неофициальный порт).

Вот выкидывание из Qt6 неюникодных кодировок опечалило, да. По-видимому, кутешники живут в мире розовых пони, где юникод уже всех убил. А в моём мире люди приносят адресные книги, импортированные из Microsoft Outlook, в cp1251, да.

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

Не повезло тем, кто в Qt4 был завязан на QtWebKit, это да (и то для них есть неофициальный порт).

А ещё на Phonon, Qt Script и Qt Declarative 1.

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

Вот выкидывание из Qt6 неюникодных кодировок опечалило, да.

Давно пора закопать все неюникодные кодировки. Qt всё правильно делает. Если надо работать с древними кодировками, то есть iconv.

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

Между тем, в нативных линуксовых приложениях такое поведение хрен настроишь

Num Lock переключить не пробовал?

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

iconv в Qt органично не встраивается.

А зачем встраиваться? Сконвертировать при открытии в UTF-8 и забыть про другие кодировки как страшный сон. При сохранении возможно сконвертировать обратно.

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

Хм, в Fedora 33 (LxQt, kate) работает. Ну наконец-то!

Проверю ещё на паре современных дистрибутивов, будет работать — возьму свои слова обратно. Просто Num Lock много лет не помогал (на сами стрелки действовал, а на стрелки с шифтом уже нет), и я себя отучил от этого удобства… :(

Спасибо!

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

Я подробно эту часть не изучал. Писать кросплатформенный мультимедиа код можно? Или надо лезть в GStreamer/DirectShow/…?

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

Ну то есть мне надо iconv со своей программой таскать, да.

Нет, в Linux и скорее всего, FreeBSD это делается достаточно малой кровью, достаточно -l в проект включить и зависимость прописать. А вот для винды придётся абсолютный путь к библиотеке в файл проекта писать и саму библиотеку с программой таскать.

Это не говоря о том, что кода придётся писать намного больше вне зависимости от ОС. Там придётся строки переводить в char* и назад. В QtCore была элегантная концепция текстового кодека, нет, кому-то понадобилось её сломать.

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

С условным QTextCodec ты получал возможность конвертаций вроде WIN-1251 => UTF-8 на огромном количестве платформ: Windows, macOS, Linux, UNIX-like, Haiku, Android, iOS, BlackBerry. А с условным iconv тебе нужно будет обеспечить возможность работы этой утилиты/библиотеки под требуемые тебе платформы самому.

Это если я правильно понял @hobbit и если из QTextCodec в Qt 6 действительно удалили всякие там KOI8-R и CP-1251, сам я ещё не проверял.

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

Повторюсь: gtk2 есть прямо в репозиториях, готовый. У дебиана нашёл только dev пакеты. Я в курсе, что можно собрать из исходников, но это не одно и то же.

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

Я сам тоже не проверял (кстати, надо это сделать). Но даже если он там осталось — QTextCodec сейчас переехал в модуль с говорящим названием Qt5Compat. А в основном коде теперь другие классы, и они уже Unicode-only.

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

Писать кросплатформенный мультимедиа код можно? Или надо лезть в GStreamer/DirectShow/…?

Да. Но тем кто был завязан на Phonon из Qt 4 – не повезло. Особенно не повезло Amarok, Clementine, Strawberry. Первого, наверное, как раз и убил Phonon, приложение не получило вовремя порт на Qt 5 и умерло.

Забавная весть – порт на Qt 5 осуществлён только сегодня: Amarok 2.9.71

Спустя чуть ли не десяток лет после выхода Qt 5. Когда Amarok никому уже не нужен.

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

Кстати, а в winapi же ЕМНИП вместо нормального utf8 какой-то NIH-треш?

Он везде. В Qt внутреннее представление строк – UTF-16, в Java – тоже.

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

Кстати, а в winapi же ЕМНИП вместо нормального utf8 какой-то NIH-треш?

Там нативная кодировка UTF-16. Начиная с Windows 10 сделали возможность переключить ANSI функции с 8 битными строками на UTF-8. Почему-то этого долго делать не хотели.

Вообще введение в WinAPI UTF-16 и A/W функций — это скорее fail, в Линуске в итоге лучше вышло. Могли бы сразу сделать UTF-8 как одну из кодировок тем более в Windows 3.1/95 уже были мультибайтные кодировки такие как Shift_JIS (CP932).

Кстати японскую кодировку Shift_JIS можно рассматривать как некую альтернативу Юникода, там есть поддержка многих языков включая русский.

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

Он везде. В Qt внутреннее представление строк – UTF-16, в Java – тоже.

И в JS-движках тоже. Чтобы бегать по строке в цикле было проще и резать её на части. UTF-8 подразумевает проход по каждому символу для выяснения его длины.

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

UTF-8 подразумевает проход по каждому символу для выяснения его длины.

UTF-16 тоже. Один символ может состоять из одного или двух 16 битных wchar_t.

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

Для O(1) в любом случае нужен UTF-32.

Вообще с UTF-16/32 слишком много возни: UTF-16BE, UTF-16LE, BOM. У UTF-8 такого нет.

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

Для O(1) в любом случае нужен UTF-32.

На практике обращение к юникодным символам (codepoint) по индексу обычно не нужно. Также один отрисовываемый глиф может состоять из нескольких юникодных символов (смайлы, лигатуры, арабская и другие сложные письменности).

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

А зачем встраиваться? Сконвертировать при открытии в UTF-8 и забыть про другие кодировки как страшный сон. При сохранении возможно сконвертировать обратно.

А если конвертировать надо не все, а только часть? Прилепленную службой, которая получила это от клиента? Разбирать с помощью Qt на куски, гнать в разобранное в буфера, коветировать, и загонять обратно?

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

ну, если ты разбираешь куски, куски и конвертируй

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

А, нет, анонимус, ты таки тупо спетросянил.

Отключение NumLock помогает, только если в XkbOptions задействовать опцию numpad:microsoft. Название опции, конечно, идиотское, к MS оно никакого отношения не имеет (кроме того, что в MS просто всё сразу сделали по логике, хе-хе). Она просто восстанавливает логику работы, что Shift+стрелка — это именно комбинация Shift со стрелкой, а не с цифрой, блин. Если numpad:microsoft не активировать, то обычные стрелки работают при выключенном нумлоке, а Shift+стрелки — при включённом. «Запомните это, дети, ибо понять это — невозможно»!

Я это по старинке воткнул в /etc/X11/xorg.conf.d/00-keyboard.conf:

        Option "XkbOptions" "grp:alt_shift_toggle,numpad:microsoft"                                                                                  

Но может, в современном дистрибутиве с systemd, т.е. в Fedora 33, это лучше прописать где-то ещё? Сразу говорю, файла /etc/default/keyboard, как в Debian/Ubuntu, тут нет.

Также остаётся открытым вопрос, что с этим режимом делать в Wayland? Это как-то в libinput можно настроить, или придётся страдать?

Отдельно, конечно, интересно, почему kate (а также, как я написал, wine-приложения) работают и без numpad:microsoft (а вот QtCreator и Falkon — не работают)…

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 4)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.