LINUX.ORG.RU

Релиз Trinity R14.0.7

 , , ,


1

3

30 декабря 2019г. состоялся релиз проекта Trinity Desktop Environment, форка ветки KDE 3.5. Проект продолжает развитие парадигмы традиционного окружения рабочего стола, основанного на Qt. Проектом поддерживается также библиотека (T)Qt3, так как Qt более не поддерживается официальным разработчиком. Окружение может быть установлено и использовано наряду с новыми версиями KDE.

Краткий список изменений:

  • Улучшенная поддержка стандарта XDG
  • Поддержка MySQL 8.x
  • Добавлена возможность сборки TDE с библиотекой LibreSSL вместо OpenSSL (что позволяет сборку TDE на дистрибутивах, вроде Void Linux)
  • Начальная поддержка сборки с musl libc
  • Продолжена миграция процесса сборки с Autotools на CMake.
  • Проведена чистка кода и удаление устаревших файлов, а также удалена возможность сборки некоторых пакетов с помощью Autotools.
  • В рамках релиза проведена чистка более не действительных ссылок на веб-страницы.
  • Проведена мелочная полировка UI и бренда TDE в целом. Продолжен ребрендинг в TDE и TQt.
  • Были внесены исправления, которые решают уязвимости CVE-2019-14744 и CVE-2018-19872 (на основе соответствующего патча в Qt5). Первая позволяет выполнение кода из .desktop-файлов. Вторая приводит к крэшу tqimage при обработке неправильно сформированных изображений в формате PPM.
  • Продолжена поддержка FreeBSD, а также внесены улучшения для начальной поддержки NetBSD.
  • Добавлена поддержка DilOS.
  • Несколько обновлена локализация и переводы.
  • Поддержка новых версий libpqxx
  • Улучшено обнаружение установленной версии ЯП Ruby
  • Поддержка протоколов AIM и MSN в мессенджере Kopete приведена в рабочее состояние.
  • Починены баги, которые затрагивали SAK (Secure Attention Key — дополнительная прослойка безопасности, требующая от пользователя нажатия C-A-Del, например, перед входом в систему)
  • Починены баги в TDevelop
  • Улучшенная поддержка TLS в современных дистрибутивах

Пакеты подготовлены для Debian и Ubuntu. В скором времени станут доступны пакеты для RedHat/CentOS, Fedora, Mageia, OpenSUSE, и PCLinuxOS. SlackBuild'ы для Slackware также доступны в Git репозитории.

Release log: https://wiki.trinitydesktop.org/Release_Notes_For_R14.0.7

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



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

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

Да, Qt гораздо больше, но в линуксе реально необходим только графический тулкит.

Толсто.

Здесь замкнутый круг. Необходимость использовать QString сильно усложняет жизнь тем, кто хочет использовать Qt из неqtшных проектов. И наоборот. Поэтому таких проектов мало.

Ой, я умоляю. Здесь дело в другом. Далеко не каждая программа общего назначения достойна того, чтобы в ней выделяли неграфическое ядро. Если «неграфики» <20%, овчинка выделки, скорее всего, не стоит. То есть множество проектов уже отсевается.

Там же, где это реально обосновано (как минимум, медиаплееры всякие), Qt-фронтенды делают, и QString им не мешает.

А вот ещё выдержка из описания API GTK:

gtk_window_set_title (GtkWindow *window,
                      const gchar *title);

Какая разница, во что преобразовывать из std::string — в QString или в gchar*?

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

Да, Qt гораздо больше, но в линуксе реально необходим только графический тулкит. Толсто

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

Если «неграфики» <20%, овчинка выделки, скорее всего, не стоит.

Во-первых, это зависит от трудоёмкости, а трудоёмкость зависит в том числе от наличия QString.

Во-вторых, множество (большинство) программ написано на C[1], а значит использовать Qt проблематично.

В-третьих, следует стремиться к унификации интерфейсов, чтобы уменьшить трудоёмкость перехода с тулкита на тулкит. Идеально - чтобы был единый API.

Вообще я считаю что свободному софту не нужно столько тулкитов (их вроде 3 - qt, gtk+, wxwidgets). Одного вполне хватило бы. Можно и несколько, но со стандартизированным API для С и для С++.

А вот ещё выдержка из описания API GTK:

Для С++ используется gtkmm, а у него свой скелет в шкафу[2], но там хотя бы utf-8.

Конечно виновны в этом прежде всего авторы С++, которые уже почти 40 лет водят разработчиков по пустыне без капли юникода.

  1. https://sources.debian.org/stats/
  2. https://developer.gnome.org/glibmm/unstable/classGlib_1_1ustring.html
sena ()
Последнее исправление: sena (всего исправлений: 2)