В Q4OS отлично работает.

У многих SoC типа AllWinner и Beaglebone (TI Sitara)

инфы по перешивке загрузчика внутри проца нет в публичном доступе, наверно и у других нет :)

Ну речь про то что не вшито в чип.

У остальных еще хуже

Сколько ест тринити?

Около 200 метров.

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

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

Спасение утопающих - дело рук самих утопающих. )

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

надо просто выкинуть из проекта всё qt, что не связано с виджетами.

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

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

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

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

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

папки жёлтые

Тыц

p.s. TDE3.5.12/SL12.2

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

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

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

маловато будет...!!! - сам далее рули, руками, мымслями, пальцами по клавитуре... :о)

p.s. Slackware 12.2

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

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

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

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

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

Если писать исключительно под Linux/FreeBSD, оно вроде и ничего

Так большинство СПО для онтопика и пишется. Так что всё в порядке.

Ну строго говоря, большинство СПО пишется кроссплатформенным. Даже DarkTable вон, под винду портировали.

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

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

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

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

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

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

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

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

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

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

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

p.s. Slackware 12.2

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

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

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

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

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

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

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

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

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

в новой версии C++ нормальная поддержка юникода наконец будет реализованы на уровне языка

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

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

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

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

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

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

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

С++23

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну они просто flat контейнеры не осилили(зато operator<=> приняли, лол), куда уж тут до юникода

p.s. Slackware 12.2

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

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

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

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

TDE get

лучше

На самом деле, Slackware 14.2 с https://github.com/Ray-V/tde-slackbuilds зело хорош.

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

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

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

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

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

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

TDE get

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

зело хорош

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

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

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

А что за тема на скрине? Пластик? Как-то слишком аккуратно.

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

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

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

Несколько лет назад, я пробовал 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)

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

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

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

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

Просто третьекеды уже были с жирком. Это они только относительно 4-й жиробасины худыми казались

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

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

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

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

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

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

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

Ну может быть, мне последние лет 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. То есть произойдёт взаимное обогащение.

там же на втором плане панель управления с выбранной темой

Около 200 метров

Ну что ты врешь, милый, она сотню ест, не больше. Врунишка ;)

Владимир

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

Вот только 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 дал бы меньше проблем. Кстати, вопрос: много ты таких проектов в опенсорсе знаешь? :)

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

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

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

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

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

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

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

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

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

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