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

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

Мне кажется тебе надо копать в сторону скинов и кастомизации для КДЕ 3. Раньше очень мощное сообщество было. Есть аналогичное для троицы, но оно небольшое. И беда в том что ты не можешь готовые скины с третьекед использовать - поменяли синтаксис третьего кьюта.

Не хватает тем оформления Тринити. Ну не нравится мне голубая гамма в темах. Хочу желтые папки.

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

Как - я уже рассказал. За исходный материал можно брать темы KDE3 и портировать.

Я не могу найти ни одной кде 3 темы нормальной, чтобы папки жёлтые были и остальные значки не голубой цветовой схеме. Нашел сайт https://www.trinity-look.org/, (который без VPN не откртывает, вот это загадка, за что его банить). Думаю может из другого ДЕ стащить, а по хорошему надо искать того кто нарисует.

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

Тогда при переходе к виджетам очень громоздкий код будет, нафига оно надо.

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

sena ()
Ответ на: папки жёлтые от sunjob

Re: папки жёлтые

Ищу на https://store.kde.org/browse/cat/104/page/12/ord/latest/, тоже еле открывает, картинки не показывает без впн. Кому он мешает… Не могу найти подходящую.

Тыц одни только иконки папок желтых неплохо, но не достаточно :-(

SL12.2 это Scientific Linux, не соображу.

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

Qt-шные классы помимо виджетов не нужны

Жду, примера чем в std:: можно заменить QTextCodec, например (ЕМНИП, в последних стандартах C++ что-то постоянно пилили с кодеками, потом запиленное объявляли deprecated…)

QtXml, QtSql (хотя не уверен, насколько последний актуален для DE, но вообще это киллер-модуль). Кроссплатформенные обвязки для всякой платформозависимой мелочи типа QLibrary опять-таки (в SDL свою обвязку запилили, кстати).

Да, можно молиться на юниксвей и оставить только виджеты, но в итоге человеку, который пишет кроссплатформенный софт для конечных пользователей, придётся собирать свой собственный фреймворк из разнородных компонентов. Если писать исключительно под Linux/FreeBSD, оно вроде и ничего, а как только потребуется переносимость хотя бы под винду и макось, со сборкой всего этого сразу возникает куча проблем, с которыми программисту приходится трахаться ВМЕСТО написания кода. Всякие MSYS и цигвины не от хорошей жизни существуют. Поэтому отношение к выкидывателям у меня, скажу честно, нехорошее.

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

Жду, примера чем в std:: можно заменить QTextCodec, например (ЕМНИП, в последних стандартах C++ что-то постоянно пилили с кодеками, потом запиленное объявляли deprecated…)

Не всё хорошее что есть в Qt есть в std, к сожалению. Но абсолютно всё, что уже есть в std необходимо как можно скорее выкинуть из Qt безжалостно и твёрдою рукой. А есть уже довольно много. К сожалению разработчики Qt продолжают тянуть это наследие за собой. Если бы они выкинули всю эту ненужную требуху, то во-первых у них уходило бы гораздо меньше работы на поддержку, во-вторых библиотеки похудели бы в разы.

QtXml, QtSql имеют право на жизнь, но должны быть полностью отдельными модулями (так оно по-моему и есть сейчас), а то и проектами…

возникает куча проблем, с которыми программисту приходится трахаться ВМЕСТО написания кода

Трахаться как раз приходится тем, кто выбрал когда-то Qt для задач не связанных с GUI (я вот в данный момент этим и занимаюсь) для «переносимости». Легаси же код, написанный без QString, QPtrList и т.п. отлично работает и собирается.

Кстати, а зачем тебе QTextCodec?

sena ()

Re: Это все, канечна, весьма интересно, но междумордие (по другому сложно сказать в 2020-м году) оставляет желать лучшего. Ибо жуть энд кошмарЪ!

Тебе - само то, как раз сделано для инвалидов, не сумевших нажать пару кнопок в графическом конфиге.

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

К сожалению разработчики Qt продолжают тянуть это наследие за собой.

Потому, что они понимают, что разработчики прикладных программ хотят добавлять новые фичи в свои программы, а не трахаться с адаптацией к новым версиям Qt. Был уже адок с переходом Qt3 -> Qt4.

Кстати, а зачем тебе QTextCodec?

Например, для поддержки всяких пользовательских форматов файлов, в которых сплошь и рядом встречаются ANSI-кодировки и тому подобное. А то и зоопарк кодировок в одном файле. Я тут уже кидал ссылку на свою заметку, кину ещё раз.

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

Что тебе мешает из нескольких тем собрать одну?

Чтобы сделать из нескольких одну, надо найти эти несколько тем. Я не нашел ни одной темы в голубых тонах. Я повторяюсь. Не знаю по какой причине, но в СПО мире любят рисовать иконки в голубых тонах. В Q4OS та же голубизна, впрочем как и в остальных дистрибутивах с ТДЕ,

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

разработчики прикладных программ хотят добавлять новые фичи в свои программы, а не трахаться с адаптацией к новым версиям Qt. Был уже адок с переходом Qt3 -> Qt4.

Дык и я о чём. Как раз когда был переход Qt3 -> Qt4 и нужно было половину Qt выкинуть/отделить. Вместо этого они продолжают тянуть за собой устаревший код и ещё небось жалуются что им не хватает разработчиков.

А раз уж кто-то взялся за Qt3, то можно сделать это правильно, взяв из Qt5 только необходимое и выкинув хлам.

QTextCodec … для поддержки всяких пользовательских форматов файлов, в которых сплошь и рядом встречаются ANSI-кодировки и тому подобное

Подобного рода специфические задачи (к тому же не имеющие никакого отношения к современности, а существующие лишь для поддержки устаревшего кода) не имеют никакого отношения к GUI и не должны быть частью Qt, как и многое другое. Нужно для начала научиться делать хотя бы одну вещь хорошо, чем кучу вещей посредственно. Пихать в библиотеку что-то только потому что это кому-то когда-то понадобилось… Тем более, когда есть ICU и в новой версии C++ нормальная поддержка юникода наконец будет реализованы на уровне языка.

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

Ну ищи. Под кде3 тонна всякого была.

Тебе писать легко, а по факту ни одной не нахожу, ни одной Карл. Их или не было или пропали куда-то или я совсем не умею искать.

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

Откуда дровишки?

на хабре писали

https://habr.com/ru/company/yandex/blog/458938/

С++23

Началась работа над крупными вещами, включая адаптацию Boost.Process для стандарта, переосмысливание работы с файлами и вводом/выводом, линейную алгебру, юникод, 2d графика, аудио, JIT компиляцию C++ кода.

Так что очень скоро, году эдак к 2025, можно будет наверное пользоваться

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

Подобного рода специфические задачи (к тому же не имеющие никакого отношения к современности, а существующие лишь для поддержки устаревшего кода)

Да-да, расскажите пользователям той же MyPhoneExplorer, что их любимая программа — «устаревший код» и «не имеет отношения к современности». Передо мной стояла задача — научиться читать файл её формата. Благодаря QTextCodec я это сделал лаконичным образом, ничего не таща в программу.

Да, так чего там с заменой QTextCodec средствами STL? Или предлагается таки тащить сторонние либы? С libiconv я, если что, работал. С ICU не работал, насколько я понимаю, это опять-таки сторонняя либа, просто более современная. Да, с ними задача будет выполнена, но код будет более громоздкий, и опять-таки для поддержки всяких виндов и прочего офтопика усилий придётся приложить больше, чем хотелось бы. Qt мне сейчас даёт возможность тратить на винду минимум времени.

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

расскажите пользователям той же MyPhoneExplorer, что их любимая программа — «устаревший код»

мне очень жаль

Благодаря QTextCodec я это сделал лаконичным образом, ничего не таща в программу.

То что ты решил какую-то задачу с его помощью ничего не меняет. Давай включим в Qt библиотеку для расчёта паровозных котлов, ведь она такая хорошая, я с её помощью решил задачу… Пусть QTextCodec существует, но в рамках какой-нибудь другой библиотеки.

Да, так чего там с заменой QTextCodec средствами STL? Или предлагается таки тащить сторонние либы?

Предлагается выделить библиотеку для создания графического интерфейса и сосредоточиться на ней, при этом всё остальное либо выкинуть либо выделить в отдельный проект(ы). В частности да, QTextCodec к созданию GUI никакого отношения не имеет.

Но прежде всего речь шла о тех классах, которые не просто не имеют отношения к GUI, а вообще не нужны и которые можно просто выкинуть. К ним в частности относятся разнообразные qtшные контейнеры.

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

Вряд ли скоро. К 2025 точно нет. Лет через 10 - возможно

Это ужасно, но ты можешь оказаться прав. Я всё же надеюсь что затягивать не будут и предварительная реализация будут доступна даже раньше.

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

p.s. Slackware 12.2

Ясно, посмотрю.

имменно эту версию не надо смотреть, это очень старая :о)

актуальная не сегодня sl14.2 or sl14.2+/current

но! для ознакомления с TDE лучше использовать дистрибьютивы линукса с «родными» пакетами TDE (debian, ubuntu...)

TDE get

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

Когда мне что-то нужно я именно так делаю. Поспрашивай в тематических сообществах тогда или тут отдельную тему запили.

Честно, мне твои советы кажутся абсолютно бесполезными. Ты говоришь очевидные вещи, которые и без тебя ясны. Вот если бы ты дал ссылку на скачивание темы, тогда я понимаю.

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

имменно эту версию не надо смотреть, это очень старая :о)

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

но! для ознакомления с TDE лучше использовать дистрибьютивы линукса с «родными» пакетами TDE (debian, ubuntu…)

У них на сайте есть Убунтовская сборка.

TDE get

У меня ни разу за несколько лет не получилось по этим инструкциям поставить ни на Дебиан ни на Убунту.

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

зело хорош

был-бы... если бы выкладывал пакеты/сборки

а так он «просто хорош» :о)

зы а вообще, совсем правильно «для посмотреть» будет воспользоваться лив-диском с TDE (скачал, посмотрел, задокументировал свои мысли :о)))

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

расскажите пользователям той же MyPhoneExplorer, что их любимая программа — «устаревший код» и «не имеет отношения к современности».

А умеет ли MyPhoneExplorer в разные DPI, например?

Если нет - то их любимая программа не иначе как «устаревший код». А то новые пользователи придут и станут удивлённо спрашивать - «почему везде буквы нормальные, а там мелкие».

gedisdone ()

Несколько лет назад, я пробовал TDE в Debian 8. Я сделал free -m и ужаснулся тому, сколько памяти занимает система. // И да, я знаю, что в первой строчке всегда показано, что занято чуть ли не 99% памяти, а во второй строчке показывают используемую память за вычетом кэша, то есть реальное значение

Почему так? У меня несколько версий. Либо опции сборки, может в моей предыдущей ОС (openSUSE 11.4 с подключенным репозиторием KDE:KDE3) использовался -Os, а тут - какие-нибудь другие опции, которые делают бинарники более жирными. Либо разработчики TDE сделали код слишком жирным относительно KDE 3.5.10. Либо жирный сам Debian, а DE - лёгкое.

P.S. KDE 3.5.10 включает в себя поддержку HAL во многих своих компонентах, а это не канон. HAL - гномовский. Использует Dbus. А надо, чтобы никакого Dbus в памяти вообще не было, а был только DCOP.

Мне кажется, что KDE 3.3 и 3.4 лучше, чем 3.5. Возможно, даже оперативы меньше едят, а в 3.5 добавилось много жирного кода. Но я не проверял - надо проверить потребление памяти в SUSE 10.0 (KDE 3.4) и SUSE 10.1 (KDE 3.5)

ZenitharChampion ★★★★★ ()

Ну извини, делать за тебя я не подряжался. :D А что незнакомому человеку в интернетах очевидно или нет - мне неизвестно.

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

Может ещё ты ставил ТДЕ поверх уже установленного ДЕ и что-то от него грузится в память. Я теперь ставлю систему без графического окружения, а сверху тринити.

Ещё можно не ставить всё окружение, а только нужные тебе пакеты.

Также попробуй Девуан как базис - он легче.

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

Ну фишка третьих кед была в том что они тебе давали именно полноценную среду - системно выстроенное окружение, а не просто оконный менеджер. Потому и называется Desktop Environment.

Как я выше написал ты можешь не ставить набор по умолчанию целиком, а поставить только нужные тебе компоненты.

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

Ставить библиотеку для такой классической задачи как перекодировка текста в один ряд с расчётом паровозных котлов — это ну очень толсто. Кстати, юникоды тоже бывают разные, так что даже похоронив всякие OEM, ANSI и ISO 88**-* (чего у пользователей и близко не наблюдается), мы вопрос перекодировки не закроем.

Но прежде всего речь шла о тех классах, которые не просто не имеют отношения к GUI, а вообще не нужны и которые можно просто выкинуть. К ним в частности относятся разнообразные qtшные контейнеры.

Списки и вектора, возможно, действительно можно не таскать (я, кстати, в каких-то проектах использовал std::vector совместно с кутешными классами, недостатков не нашёл, возможно, плохо искал). А вот если выбросить тот же QString, та же перекодировка, например, подкручиваемая через внешнюю библиотеку, будет более громоздкой.

Чего там кстати, в мире std:: вместо Qt Linguist брать? Gettext прикручивать? Или появилось что-то стандартное?

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

Ставить библиотеку для такой классической задачи как перекодировка текста в один ряд с расчётом паровозных котлов — это ну очень толсто.

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

А вот если выбросить тот же QString, та же перекодировка, например, подкручиваемая через внешнюю библиотеку, будет более громоздкой.

С какой стати? Если QTextCodec кому-то полезен, то достаточно его переделать для работы с std::string и всё. А вот QString в qt3, как и другие COW контейнеры никуда не годятся из-за проблем с многопоточностью. Вместо того чтобы переписывать это всё и доводить до ума, гораздо лучше было бы выкинуть и взять рабочее и стандартное. И если аналога для QTextCodec в std нет и этим ещё как-то можно оправдать его существование, то для контейнеров такого оправдания нет. Hекоторые контейнеры таки были выкинуты из qt4 (типа QPtrList, QDict), другие были существенно переделаны (типа QByteArray и QString), но последовательности разработчикам qt не хватило и они продолжают тянуть это из версии в версию.

Чего там кстати, в мире std:: вместо Qt Linguist брать? Gettext прикручивать? Или появилось что-то стандартное?

В бусте появилось boost::locale основанное на gettext. В std вроде нет пока. Однако нет никакой проблемы использовать Qt Linguist QTextCodec и дальше, но важно отказаться от использования QString. И тогда у нас будет выбор - либо Qt Linguist, либо gettext/boost, либо ещё что-то. А пока Qt завязан на QString, у всех кто пользуется Qt будут проблемы с альтернативами и им будет проще пользоваться встроенными библиотеками, завязанными на QString. Выходит замкнутый круг и QString это одно из ключевых звеньев. Если же отказаться от QString, то как для пользователей Qt откроется возможность использовать с удобством альтернативные интсрументы, типа того же gettext, так и для неqtшных пользователей появится возможность использовать инструменты Qt типа Qt Linguist. То есть произойдёт взаимное обогащение.

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

Всё это безусловно полезные вещи, но это не основание включать все эти полезные вещи в графический тулкит.

Вот только Qt — это НЕ графический тулкит. Ты сначала даёшь давным-давно устаревшее определение, а потом начинаешь предъявлять определяемому объекту претензии, что он не соответствует твоему определению. Немного смешно получается.

А пока Qt завязан на QString, у всех кто пользуется Qt будут проблемы с альтернативами и им будет проще пользоваться встроенными библиотеками, завязанными на QString. Выходит замкнутый круг и QString это одно из ключевых звеньев. Если же отказаться от QString, то как для пользователей Qt откроется возможность использовать с удобством альтернативные интсрументы, типа того же gettext, так и для неqtшных пользователей появится возможность использовать инструменты Qt типа Qt Linguist. То есть произойдёт взаимное обогащение.

В теории всё правильно. В целом я сам и за возможность выбора и за взаимное обогащение.

А при переходе к практике это превращается в анекдот:

И давно вас мучают эти эротические кошмары?
Доктор… ну почему же МУЧАЮТ?

Замкнутость и подогнанность компонентов в Qt для тех, кто ей пользуется — в большинсте случаев не порок, а достоинство. Вот чего мне в моём проекте даст gettext? Ну разве что не все платформы онлайн-перевода поддерживают Linguist, ну для своего проекта я могу выбрать сам платформу, которая поддерживает. Подозреваю, что и большинство пользователей gettext он устраивает, и вряд ли они захотят Linguist ради Linguist.

Проблемы могут возникнуть, если я цепляю внешнюю библиотеку с не-Qt-шными строками. Но и тут надо оценивать, сколько я приобрету, сколько потеряю. Кстати, некоторые библиотеки, даже будучи написанными на C++, предпочитают работать не с std::string, а вообще с char*. В этом случае получается что в лоб, что по лбу.

Рассмотрим обратную ситуацию. Нужно ли в «неqtшных» проектах вызывать «qtшные» модули? Наверное, такое бывает. Например, проект с большим количеством «невизуальной» логики. Есть ядро на чистом C++ и есть несколько фронт-ендов: с Qt, с GTK, а то и вообще сервер с веб-интерфейсом. Тут, согласен, std::string дал бы меньше проблем. Кстати, вопрос: много ты таких проектов в опенсорсе знаешь? :)

И не надо искать «оправдание» для библиотекописателей, поддерживающих совместимость. Совместимость — это нормально. Оправдываться надо не перед любителями «красивой архитектуры», а перед разработчиками прикладного кода, которым совершенно не упёрлось постоянно адаптироваться.

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

Вот только Qt — это НЕ графический тулкит.

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

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

Не вижу в чём здесь может быть достоинство, кроме как для пользователей всяких закрытых embedded с недокомпиляторами и недоstdбиблиотеками. Для них - да, это важно.

Тут, согласен, std::string дал бы меньше проблем. Кстати, вопрос: много ты таких проектов в опенсорсе знаешь? :)

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

Что очень правильно сделали в qt4+ - возможность вклиниться в цикл обработки событий. То есть теперь можно, например, поженить qt и boost::asio.

Оправдываться надо не перед любителями «красивой архитектуры», а перед разработчиками прикладного кода, которым совершенно не упёрлось постоянно адаптироваться.

Qt - одна из важнейших библиотек для свободного ПО. То что она живёт замкнутой обособленной жизнью - не очень здоровое явление.

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