Проект Xfce4 разрабатывает собственный Wayland-композитор

Убеждай себя в этом :)

На второй пост отвечать уже не буду, потому что всё сказал раньше.

Потому что ты прекратил читать что я пишу и начал создавать виртуальные нарративы.

Не ври.

Я не люблю читать ненужную мне документацию

Это я уже слышал.

А что про это написано в инструкции по установке?

Да плевал ты на инструкции, как выяснилось в истории про груб и маск.

Нет, ды дословно написал:

Нет. Фиксить баги - это достаточно широкое определение, а ты цепляешься к одной конкретной формулировке.

Очень сильно отличается.

Чем отличается-то, алло?

там какие-то очень странные тесты, по-моему несерьёзно

Неси другие.

вялый и […] подожгут фанатиков

С тех пор как завезли explicit sync в драйвера Энвидии. И допилили xdg-dektop-portal. И Flameshot нормально заработал. Жаловаться на Вялого особого смысла нет. Разве что нельзя этому xdg-dektop-portal донести, что в рамках сессии разрешаю шару вот этому приложению. Вот сколько угодно раз. Все разрешаю. Ну лет через 10, 20, наверное, подвезут.

Сишке нечего делать где-то за пределами низкоуровневой возни.

Нас решили спасти от черенка лопаты в заднице, что похвально. Но вместо него вставляют дилдо со стразами, что не очень похвально. Дилдо, кстати, будет в форме буквы Щ, потому что так решил кто-то там. Выбора нет. Привыкнешь.

Я не сильно слежу за Вейландом, но всё это очень похоже на историю с внедрением системдэ. Там где начинаются интересы Ред Хэт, начинается какая-то фигня.

В последних версиях Xfce начал жрать ОЗУ чуть ли не как KDE Plasma.

может просто утечка памяти? В 12м и 11м Дебиане в xfce было несколько неприятных утечек памяти, xfwm глючил регулярно. В 13м пока мало опыта, пока всё нормально.

Кстати, недавно на Кубунте 24 в КДЕ хотел в Дельфине (так же там файл-менеджер называется?) скопировать файл. Начал искать кнопки «Копировать»-«Вставить» не нашёл. Это особенность Кубунты24 или в КДЕ решили убрать копипасту для файлов?

У кдешников единственный шанс – быстренько переписать всё на раст.

смешно :) разве что нейросети смогут

Ctrl+C/V; меню правой кнопки.

Веришь, или нет, но про Ctrl+L я узнал сейчас впервые

Я попадал в ту же ловушку. Это не единственная проблема Гнома, там такие ловушки на каждом шагу.

Если бы в ГНУ/Линукс был один десктоп на всех, то такое можно было бы ещё как-то понять - учите документацию, горячие клавиши и т.п. Но в ситуации когда есть десяток разных десктопов, такие базовые вещи должны быть очевидны для новичка. Смотри знаменитый анекдот про редактор ed[1] .

1. https://www.gnu.org/fun/jokes/ed-msg.en.html

Ctrl+C/V; меню правой кнопки.

в меню правой кнопки нет копипасты!

ctrl-c/v тоже не работают

У меня всё есть, хз что у тебя не так.

начинаются перегоны из std::string в QString и обратно, NIH-контейнеры вместо STL

Кстати да, QString это большущая проблема. контейнеры ещё ладно, они редко необходимы, но QString…

Но опенсорс действительно страдат от ситуации «есть N решений, почти одинаковых, но немного разных», на поддержку которых тратится неуемное количество усилий. Если бы разработчики объединились, от этого бы выиграли все.

Зачем было тогда начинать Вейланд? По-твоему выходит, если бы разрабы Вейланд объединились с разрабами Иксов, от этого бы выиграли все?

Что делать с буффером средней кнопки? Хорошо, я могу согласиться, что это может путать нового пользователя, свежепришедшего с виндов или мака, но зачем было прятать фичу? Даже в интерфейсе галочки не оставили, это не нормально.

В Tweaks эта опция уже много лет как есть. Ничто не мешает этому впоследствии переехать в основные Настройки, как случилось с множеством других подобных опций.

Читаю я эту вашу ветку и вспоминаю что у меня в Дебиан в Xfce в последние годы тоже периодически стала возникать проблема с копи-пастой по средней кнопке и по контекстному меню, особенно в терминале Xfce в определённых ситуациях. Может это быть отголоском этого «обновления» в gtk+/Гноме?

Кто-то сталкивался с этим в Xfcе?

С QString нет никакой проблемы.

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

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

Вяленд начали, чтобы выкинуть иксы

Да, ты прав. В сущности ведь Иксы перед началом разработки Вейланда разрабатывал тоже в основном Ред Хэт. То есть они действительно могли принять решение разработать Вейланд, чтобы заменить Иксы. Это были одни и те же люди.

С QString нет никакой проблемы.

С самим QString пробем нет никаких, он в полном порядке. Проблема лишь в том что он не нужен.

Ну да, всё так.

Читаю я эту вашу ветку и вспоминаю что у меня в Дебиан в Xfce в последние годы тоже периодически стала возникать проблема с копи-пастой по средней кнопке и по контекстному меню, особенно в терминале Xfce в определённых ситуациях. Может это быть отголоском этого «обновления» в gtk+/Гноме?

Это обновление в master-то слили 3 недели назад, ещё даже релиза не было.

Ну и влиять на копирование непосредственно в буфер обмена это никак не должно, т.ч. у вас явно нечто другое.

Обертки для Qt пишутся элементарно, и это первое, что нужно сделать, если ты делаешь шаг в сторону.

Выбор языка си в gtk+ не случаен. Для главного, стандартного, системного тулкита крайне важно чтобы было API на всех языках, это критически важно.

Если ты разрабатываешь какой-то нишевой продукт, типа тулкит для с++ - ладно, нет вопросов. Но для стандартного тулкита нужен API на все распространённые языки и прежде всего, на первом месте - на сях (потому что очень много языков поддерживают си для биндинга). Для qt такого нет. Были какие-то попытки, но стандартного стабильного си-апи нет.

Уже одно это, несмотря на все плюсы и достоинства qt делает gtk+ куда ближе к идеалу стандартного, системного, универсального тулкита, который следует оставить, если надо будет выбирать один из двух.

Благо нам выбирать не надо и можно оставить оба. Но если такая необходимость возникнет, то выбор будет, увы, не в пользу qt.

Что же касается того, что в qt напихали много другого, помимо GUI, то это скорее недостаток, чем достоинство. Причём если некоторые вещи, типа сетевой библиотеки , можно безболезненно выкинуть, то другие, такие как QString, проникли очень глубоко и вычистить код от них будет весьма непросто.

Но это только касательно gtk+/qt. Что же касается gnome/kde, то конечно же kde однозначно лучше gnome. И хотя мне оба не нравятся, за раздутость и по дизайну, дизайн гнома и почти всех его приложений как-то особенно ущербен. Почти все приложения, что я пробовал на моей памяти, имеют какие-то фатальные недостатки. Из последнего что помню, ibus - просто не смог настроить переключение по капс-локу. Все видеоплееры, по-моему целлюлоид и ещё какой-то, тормозят, теряют кадры, пожирают ЦПУ. Даже гномовский калькулятор помню - пожирает ресурсы при очень скромных возможностях (зачем только они его тащат везде - загадка). Но и в КДЕ у меня постоянно возникали проблемы со стабильностью, так что я от него тоже не в восторге.

Уже одно это, несмотря на все плюсы и достоинства qt делает gtk+ куда ближе к идеалу

Нет. Писать интерфейсы на не-ооп языках банально неудобно. Нужность этого под большим вопросом. GTK - это псевдо-ооп. Либо интерфейс должен быть декларативным, либо объектно-ориентированным.

Что же касается того, что в qt напихали много другого, помимо GUI, то это скорее недостаток, чем достоинство.

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

вычистить код от них будет весьма непросто

Это не решает никакой проблемы и никому не нужно.

Но и в КДЕ у меня постоянно возникали проблемы со стабильностью, так что я от него тоже не в восторге.

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

Нет. Писать интерфейсы на не-ооп языках банально неудобно.

Неудобно штаны через голову надевать. Не сдержался.

При чём тут удобно или нет. Любой стандартный универсальный системный тулкит, любая системщина имеет сишный апи. Внутри там может быть что угодно, а наружу должно торчать что-то универсальное. с++ для этого, увы, просто не годится.

Неудобно штаны через голову надевать. Не сдержался.

Уровень дискуссии my ass.

Прошу прощения, конечно, но таковы жёсткие реалии. Это не выбор по принципу «удобства» или «моды» или «актуальности». Сишный API и ABI это единственный существующий стандарт, который поддерживается всем и вся. Я вообще боюсь что это навсегда (надеюсь что нет).

целлюлоид и ещё какой-то, тормозят, теряют кадры, пожирают ЦПУ

Целлюлоид - лишь обёртка над mpv

Даже гномовский калькулятор помню - пожирает ресурсы при очень скромных возможностях (зачем только они его тащат везде - загадка)

У гномовского калькулятора скромные возможности? Ты пробовал переключать режимы в заголовке? Advanced, Programming, Financial, и т. п. Один из самых фичастых калькуляторов под Линукс.

Дело не только в универсальности сишного API, но и в GObject Introspection, благодаря которому межязыковое взаимодействие удобное и простое. Есть сишная либа, которую можно легко и непринуждённо дергать из кода на JS, Python, C# или чем угодно ещё. Qt ничего подобного предложить не может.

Целлюлоид - лишь обёртка над mpv

То есть даже обёртку не смогли нормально написать. мпв работает отлично (в последнем дебиан 13 что-то отвалилось только).

гномовского калькулятора скромные возможности?

Да, причём при повышенном потреблении ресурсов. Сравни с qalculate, например

То есть даже обёртку не смогли нормально написать. мпв работает отлично (в последнем дебиан 13 что-то отвалилось только).

Ну, у меня Celluloid работает отлично. Может, в MPV у вас аппаратное декодирование включено, а в Celluloid нет?

Да, причём при повышенном потреблении ресурсов. Сравни с qalculate, например

Насчёт потребления ресурсов ничего не скажу, но скромными я его возможности для стандартного калькулятора из состава DE точно не назову. Он даже пользовательские переменные и функции позволяет определять. Тот же Калькулятор KDE явно поскромнее.

Celluloid работает отлично

Он безусловно работает, но mpv и vlc у меня работали лучше, потребляли меньше ресурсов. Спрашивается, зачем он вообще нужен? Как и калькулятор…

настройки смотрел конечно

Если я буду составлять список претензий к Гному, он будет большой и длинный, я на нём сидел до третьего, а потом ещё пару раз пытался вернуться. Не смог. Предлагал знакомым - все предпочли Xfce, все кто попользовался Xfce обратно на Гном не заманишь.

Знаю тех, кто предпочёл KDE. Таких чтобы перешли на Гном, не знаю вообще ни одного человека (кроме тех, кто на нём сидит изначально).

Ещё Гном с собой кучу сервисов тянет, типа индексации файлов и прочее, прочее, прочее, всё это жрёт память, тормозит… Не понимаю любителей Гнома вообще.

Пользоваться им как запускалкой нормального софта конечно можно, сказать что он вообще никуда не годен нельзя. Однако в качестве запускалки софта он через чур прожорлив - для этого вполне сойдёт и Xfce, в котором чуть меньше свистоперделок, но он хотя бы не жрёт ресурсы, как КДЕ и Гном.

Ну это вопрос предпочтений. Я вот, когда пришел в Линукс, перепробовал все, что возможно, но каждый раз возвращался на Гном. Крыса тоже неплоха, но мне не хватало фич в ней, к которым привык в Гном. Это к слову о субъективности количества этих фич. У других людей тоже видел, хотя, честно говоря, я линуксоидов вживую знаю десяток, включая мою родню, которых я сам пересадил (не насильно и не из идеологических соображений; не на Гном, если кому интересно😆).

Писать интерфейсы на не-ооп языках банально неудобно

Так GObject-based библиотеки так и спроектированы, чтобы ты мог писать интерфейсы на своем любимом ООП-языке. В то время как Qt - кресты безальтернативно.

Здесь даже нечего обсуждать: ты не тимлид, не архитектор, и даже не рядовой разработчик.

Ну да, конечно, в проекте КДЕ поменялась команда, поменялся проект и подменялся подход. Правда факт никуда не делся: они тратят больше денег на продукт худшего качества. Растёт ли доля QT-приложений? Я как то не заметил. У тебя есть иные данные?

Почему, при этом, ты, не написав в жизни ни одной строчки кода, берешься делать далеко идущие выводы о разработке софта - решительно не ясно.

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

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

Как строитель-конструктор заявляю: требование максимального использования типовых элементов никуда не исчезает даже если ты строишь статую Ван-Гога в масштабе 10:1. Те 16 колонн можно было заменить 2 или 4 типами или тогда уж не заниматься хренью и предложить изготовить колонны по месту с типовыми пятками и оголовками.- как оно в итоге и получилось. Потому что проектировщик, совершенно внезапно, не знал реальную конфигурацию грунта на участке и ни одно из привезённых изделий по месту не подошло. Абсолютно типовая проблема глухого телефона и оторванности от реальности. В данном случае всё началось с того, что проект был красиво нарисован на виртуальном склоне горы, не соответствующем реальному. В итоге с одной стороны он был заглублён на 3 метра а с другой стороны стоял на 2-метровой насыпи. Объём перемещённого грунта и сложность работ была очень вкусной для нас, исполнителей! Но на самом деле так делать не следовало.

А вообще, пример занятный: он буквально говорит о том, что комбинаторный взрыв до добра не доводит

Всегда можно сделать проще: вот стандартный оголовок, вот стандартная пятка. А между ними стандартный 180-й швеллер, сваренный квадратом. Длинну отрезать по месту, с припиской что не длиннее например 4,5 метров.

Это полный аналог следования стандартным api, когда от тебя требуется лишь верно его реализовать, не переусложнять систему и протестировать одно типовое состояние. Тот кто будет делать работу на другой стороне сделает то же самое и в сумме всё заработает.

Да плевал ты на инструкции, как выяснилось в истории про груб и маск.

Нет, это ты придумал и пытаешься продвигать свою виртуальность. Но по факту я воспользовался mask'ом задолго до тебя и уже тогда был недоволен что это кривой костыль при нереализованном нормальном откючении, и я установил граб0 и пользуюсь им, просто для этого надо брать не кривые а нормальные инструкции и сборки, а в Арче с этим сложно.

Чем отличается-то, алло?

Объёмом работы по обслуживанию дистрибутива. На порядок-два, всего лишь.

Не безальтернативо, а можно сделать биндинги на любой ООП-язык. На питоне с Qt писать одно удовольствие.

Да и, будем честными, плюсы в Qt - не совсем плюсы, а целый диалект, учитывая moc. Совершенно не ясно, зачем там другой язык, если можно писать на «Qt++».

Растёт ли доля QT-приложений?

Растет. Из крупных - переписывают Audacity.

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

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

Ну ладно. Конкретно я, на самом деле, могу, но среднестатистический заказчик не может.

строитель-конструктор заявляю

Очевидные вещи говоришь.

полный аналог следования стандартным api

Нет. Сферическое API в вакууме почти всегда фундаментально несовместимо со внутренней архитектурой приложения - а то и вообще с реальным миром, потому что оперирует сферическими конями. И если даже его можно сделать совместимым, то теряется значительная часть функций.

У меня как раз есть отличный недавний пример из собственного опыта. Есть такая штука - Redfish. Это стандартизированный индустриальный протокол для удаленного управления всякими ресурсами сервера. В частности, там есть протокол управления сменными носителями: вставить/вытащить образ диска, получить инфу и так далее.

В ручке получения инфы можно посмотреть, какие типы носителей поддерживаются, целым списком. Так вот: при вставке носителей выбора из списка не предусмотрено! Просто нет такого параметра. Предполагалось, что у тебя должен быть отдельный виртуальный оптический привод, и отдельный flash. Технически ты можешь сделать перечисление ["USBStick", "CD", "DVD"] для MediaTypes в информационной ручке, но в ручке вставки образа ты не можешь указать, для чего конкретно этот образ: USBStick или CD/DVD.

А у меня в КВМ привод один, и он комбинированный. Пришлось сделать костыль: если образ заканчивается на *.ISO - это CD/DVD. Потому что даже если бы я добавил кастомный параметр, утилиты Redfish ничего знать о нем не будут. И тут же этот костыль не будет работать, если ISO-образ комбинированный и юзер захочет зафорсить USBStick. Кстати, индикации того, какой конкретно тип имеет уже вставленный диск, тоже не предусмотрено. Можно добавить вендорские поля, которые, естественно, автоматически утилитами не обработаются.

Даже в таком случае подход «понаделаем стандартных API, и пусть все остальные подстраиваются» не работает. В некоторых сферах без этого никак. А в других сферах, когда предполагается, что продукт в первую очередь взаимодействует со своими компонентами, это не нужно, потому что многократно усложнит разработку и ограничит фичсет.

Нет, это ты придумал и пытаешься продвигать свою виртуальность. Но по факту я воспользовался mask’ом задолго до тебя

Ну-ну, не надо врать. Я не сказал, что ты им не пользовался - ты не пользовался им сознательно. Я всегда говорил, что ты не понимаешь, как он работает, потому что манов не читаешь и просто бездумно копипастишь команды из интернета.

Вот здесь ты с пеной у рта утверждал, что юнит:

настолько никуда не девается, что системд вообще не знает о его существовании. Его надо сначала вернуть отдельным инструментом а потом перезагрузить всю конфигурацию, причём так что проще всю систему ребутнуть

Потом ты придумал новую глупость:

почему ты думал, что systemd ничего не знает о замаскированном сервисе?

Например потому что он перестаёт реагировать на короткое имя, которое и нужно использовать вместо длинного из соображений удобства?

И когда продемонстрировал, что это не так - ты просто испарился из треда, чтобы потом просто начать повторять свою чушь, как будто ничего и не было.

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

Ты даже ни разу не запускал systemctl на замаскированный сервис, чтобы увидеть, что о нем думает systemd. А уж бредни о том, что нужно «перезагрузить конфигурацию», чтобы вернуть его в строй после размаскировки - вообще не ясно откуда взялись.

Так что можешь больше не врать людям про то, что ты знаешь, что такое mask.

Объёмом работы по обслуживанию дистрибутива. На порядок-два, всего лишь.

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

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

Еще раз: я не понимаю, зачем ты с таким ламерским подходом пользуешься линуксом. Купи себе мак и не мучайся.

можно сделать биндинги на любой ООП-язык

можно

Ну и почему не делают (да, я знаю про PyQt)? А почему для ГТК делают? Может быть, потому что ГТК в этом плане на много шагов впереди?

Qt - не совсем плюсы, а целый диалект

Офигеть теперь. То есть на ГТК можно писать на практически любом ЯП, а на Qt - на особом диалекте одного из? А где плЮсы-то?

Делают. Много чего отмирает за ненадобностью, потому что цугундерные языки сами по себе мало кому нужны.

На Python сделали, потому что язык популярен и на нем в принципе удобно писать гуйню к чему-то. Это было даже с Tkinter нормально, а уж с Qt - и подавно.

ГТК в этом плане на много шагов впереди

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

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

Я не рассматриваю это, как плюс

А зря. Инфраструктура GTK/GLib изначально спроектирована очень дружелюбно в плане добавления поддержки новых языков. Больше поддерживаемых языков -> больше разработчиков -> больше приложений. Ещё и меньше порог входа. Под Гном я могу разрабатывать хоть на JS. Gnome Maps, например, написан на JS. Это удобно, потому что приложение написано поверх сервиса OpenStreetMaps и там в любом случае было бы много JS кода. Теперь представь, как бы это было реализовано на Qt.

Ещё и меньше порог входа.

От того софт у нас и превращается в говно. Что до редких языков - человек, пишущий на Vala, явно будет знать не только его и, скорее всего, он вполне способен писать на Qt++.

Gnome Maps, например, написан на JS

Десктопные приложения должны быть нативными.

Теперь представь, как бы это было реализовано на Qt.

Нативным кодом без всяких проблем. Я напоминаю, что в былые времена, до того, как гугл ударился в тотальный веб, у них было нативное десктопное приложение Google Maps, написанное на Qt. И отлично работало.

Короче, ты неубедителен.

Десктопные приложения должны быть нативными.

Пошла религия.

Нативным кодом без всяких проблем. Я напоминаю, что в былые времена, до того, как гугл ударился в тотальный веб, у них было нативное десктопное приложение Google Maps, написанное на Qt. И отлично работало.

Да? И сложность разработки и поддержки его, интеграции с другими сервисами, веб и мобильными приложениями была такой же? Так почему же Гугл решил дропнуть нативную версию? Что случилось?

человек, пишущий на Vala, явно будет знать не только его и, скорее всего, он вполне способен писать на Qt++

Способен - вероятнее всего. Захочет ли - не факт. Я не особо разработчик, но если бы у меня был бы выбор, писать на Vala или на C++ (пусть даже на диалекте) при прочих равных, я бы долго не раздумывал.

Пошла религия.

Пошла клоунада.

За последние двадцать лет компьютеры стали быстрее в разы, а софт как тормозил - так и тормозит. Можешь посмотреть, например, что происходит в 11 винде с календарем на жаваскрипте. Если ты не можешь сложить два и два - это уже диагноз необучаемости.

почему же Гугл решил дропнуть нативную версию? Что случилось?

Гугл написал свой браузер и свои расширения к вебу, превратившиеся в стандарты. Ты, похоже, не особо знаешь историю.

я бы долго не раздумывал

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

Он безусловно работает, но mpv и vlc у меня работали лучше, потребляли меньше ресурсов

Насчёт VLC не скажу, а с MPV я какой-то ощутимой разницы не заметил. Знаю, что в последнем можно включить более экономный вывод через dmabuf в Wayland, но то не проблема Celluloid, что это не поддерживается в libmpv: GTK4 такой прямой вывод вполне умеет.

Таких чтобы перешли на Гном, не знаю вообще ни одного человека (кроме тех, кто на нём сидит изначально).

Ну вот я с небольшими перерывами был пользователем KDE где-то 15 лет — и перешёл на тогда ещё GNOME 3.30. И обратно меня теперь не загонишь.

Я понимаю тех, кто перешёл после GNOME 2 на другие окружения: GNOME 3 предложил смену парадигмы, и к этому далеко не все были готовы — никто не любит менять годами сформированные привычки, да и синдром утёнка списывать со счетов не стоит. Ну и ранние версии третьей ветки были, мягко говоря, так себе.

Лично я, как и большинство тогда, хихикал над GNOME 3 и повторял типичные смехуёчки вроде «интерфейса для мобилок». И только вконец доставшие меня KDE заставили наконец взглянуть на GNOME без предрассудков — и оказалось, что он офигенен. И забавно, но весь чёрный пиар имел здесь ровно обратный эффект: на фоне низких ожиданий реальность воспринималась ещё лучше.

Да, не во всём, и да, у него тоже полно недостатков, — но лично для меня это лучшее окружение в Linux на данный момент.

Ещё Гном с собой кучу сервисов тянет, типа индексации файлов и прочее, прочее, прочее, всё это жрёт память, тормозит… Не понимаю любителей Гнома вообще.

Там много полезного, чем я пользуюсь. То же индексирование файлов позволяет быстро их находить, а сервис сетевых учётных записей — элементарно их интегрировать (например, добавив учётку Google, я тут же получил доступ к Google Drive из файлового менеджера и почте, а также синхронизацию контактов, событий календаря, напоминаний и проч.).

И лично у меня ничего не тормозит. Где-то до версии 3.38 GNOME, действительно, регулярно подлагивал, но во многом благодаря работе Canonical сейчас всё летает.

Однако в качестве запускалки софта он через чур прожорлив - для этого вполне сойдёт и Xfce, в котором чуть меньше свистоперделок, но он хотя бы не жрёт ресурсы, как КДЕ и Гном.

К Xfce я отношусь хорошо, но разница в потреблении памяти там уже не настолько велика, чтобы только этим оправдать его использование на машинах с 16 ГБ и выше, отказавшись от удобств, предоставляемых другими окружениями.

Если же вам нужно простое окружение, и вы предпочитаете Windows-like workflow, то крыска — действительно, хороший выбор.

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

Как ты ловко со стула на стул скачешь. То есть когда много разработчиков и используются широко распространённые технологии, это хорошо всё же?

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

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

Gnome Maps, например, написан на JS

Десктопные приложения должны быть нативными.

Хм, так обычно говорят про программы на электроне, которые с собой целый браузер тащат и обычно плохо интегрируются в окружение, — но чем плохи программы на скриптовых языках вроде тех же Python или JS, использующие нативные тулкиты? В десктопных приложениях часто нет каких-то сложных вычислений, и узкое место — это ввод/вывод, сеть или действия пользователя.

Тот же QtQuick вовсю использует JS, например.