LINUX.ORG.RU

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

 ,


2

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 ()

Ответ на: комментарий от 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

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

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

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

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

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

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

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

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

Спасибо!

hobbit ★★★★★ ()
Ответ на: комментарий от 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 ★★★★★ ()
Ответ на: комментарий от 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-треш?

Там нативная кодировка 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 ()
Ответ на: комментарий от khrundel

Таким образом выпуск QT5 под BSD никак не повлияет на бизнес Qt Company, он повредит самой KDE: сейчас, когда Qt5 лицензирована под GNU, любой, изменяющий её под свои нужды вынужден отдавать код, а так все будут менять у себя, а назад не выпускать.

Там же написано, что under BSD or other open source license.

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

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

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

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

Короче, лучше б бросили эти опасные Кути и пилили ГТК

GTK уже поломан до неюзабельного состояния, из десктопного (не недопланшетного как GTK 3+) современного самодостаточного тулкита остался практически только Qt.

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

Что поломано, дизайн и жирный заголовки?

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

Это ж легко убирается

Огромные отступы в дизайне легко не убираются потому что регулярно ломают темы.

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

Не знаю, я б пользовался Гномом, если бы он не был таким кастрированным и его приложения тоже унылые в основном, но gThumbs норм и ещё несколько, не помню.

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

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

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

anonymous ()

GTK(GIMP ToolKit) появился как интерфейс для графического редактора GIMP. Потом стал самостоятельным продуктом.

Смешные психологические драмы кедералов в комментах. Gimp до сих пор на GTK2 во многом. Софт на любых языках использующий GTK в начале программы указывает какую версию API GTK нужно.

Gimp будет полностью переведён на GTK3 в версии 3.0, неизвестно когда будет этот релиз. GTK2 получит скоро последний релиз, и на этом будет конец поддержки.

А текущая версия GTK 4.0.3, четвёртое поколение.
Все эти версии решали задачи фундаментально, появлялись проекты как специальный язык Vala(похож на C#), потенциальные IDE как Anjuta. Решались проблемы с экранами высокой плотности. Система сборки Meson из проекта GStreamer, на нормальном языке Python в отличии от CMake.
Все с Autotools перешли на Meson. Облегчается сборка на разных платформах.

GTK/Gnome первыми имплементировали Wayland.
И тому подобное.

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

Tk, iup, wxWidgets, nana, flutter, electron - что угодно

Раньше многими считалось что GUI должен быть «родным», обязательно выглядеть как текущая тема в ОС.
Но более практичное правило поддерживать хотя бы light и dark темы, без полного копирования look&feel.

Tk давно зашёл в тупик со своими улучшенными widgets, которые вроде бы настраиваемые несколькими опциями.
wxWidgets в парадигме рисования копий дефолтных элементов ОС, выглядеть «native».
Electron…

На Vulkan надо переходить. В Python хороший GUI Kivy на OpenGL. Но GL депрекнули как-бы, особенно Apple, и в развитии мало энтузиазма.
В Go есть Gio, immediate mode GUI, тоже OpenGL но рассматривается Vulkan. GTK4 внедряет Vulkan.

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

Там же написано, что under BSD or other open source license.

Так оно уже под, цитирую «GPL and LGPLv3». Ну вот это соглашение позволяет KDE перевести на BSD, что никак не повлияет на бизнес Qt (ну, т.е. у них может появиться конкурент, который начнёт с Qt5 в то время как сами кутэшники будут иметь фору в виде торговой марки и +1 версии.

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

Для меня Gnome уже несколько лет лучшее что можно придумать по эргономике.
Единственно что казалось странным, это расширения только на javascript(GJS). Но потом понимаешь что темы лучше всего будут делать webdevs, и с JS они уже знакомы.

В начале ещё пересматривал аргументы пропаганды что Gnome стал хуже, что там якобы в неправильном направлении движутся.
Но каждый раз это какая-то туфта оказывалась, а не аргументы. Что-то у них всё ломалось бедненьких, и это всегда драма.

Настройки которые нужны после установки это переназначить пару клавиш в xkb для удобства в Emacs, и в Gnome этого нет, кажется(в Gnome Tweaks можно поискать).

tp_for_my_bunghole ()
Последнее исправление: tp_for_my_bunghole (всего исправлений: 1)