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

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

Тут, кажется, расхождение интерпретаций понятия фрагментации. Я говорил не о разнообразии как положительном следствии существования множества реализаций, а о несовместимости и отсутствии общих стандартов, на которые могли бы опираться сторонние разработчики. Это вредит экосистеме Linux как платформе.

А, ну в этом смысле могу согласиться, да. Когда есть стандарт, лучше, чем когда его нет. Впрочем, как можно было бы стандартизировать подобные тулкиты, причём так, чтобы это не получилось, как порой получается у XDG (я не про удачные вроде Base Directory, а про те же .desktop-файлы, например) и красношапки — что лучше бы вообще не было стандарта, чем такой — я не особо представляю, если честно.

Хотя какой-то стандарт на каком-то очень базовом юзерском уровне, чтобы они, например, предпочитаемую цветовую схему из одного и того же места могли читать, хотя бы на уровне main bg, secondary bg, fg, был бы не лишним.

Безопасность – это когда вводят технику безопасности при работе с инструментом, а не отбирают инструмент со словами «это тебе не нужно».

Сторонники Wayland постоянно употребляют «кейлоггер» в качестве ругательного слова. Между тем, кейлоггер делает ровно то, что указано в его названии – журналирует клавиатуру. Это не какое-то абсолютное зло, которое злые хакеры (коммунисты/либералы, евреи/арабы и т.д.) подсовывают тебе с целью насолить. Это инструмент, который может использоваться как во благо, так и во зло. Во благо (кроме потребностей всяких ИБшников) – это, например, когда ты записываешь последовательность действий с целью их последующей автоматизации, да и вообще повторяемости.

Техника безопасности – это, например, взять за основу иксовый подход и обложить его системой прав. Два белых списка, каким программам можно перехватывать и у каких можно перехватывать. Можно даже цепочками – кому у кого можно. Но да, просто отобрать инструмент и говорить, что это безопасность, намного проще. Те, кому это надо, просто пойдут на винду, где спокойно работает условный AutoIt (это не про кейлоггинг, но тоже про автоматизацию работы других программ). Вот и всё.

А потом на ЛОРе опять (другие люди, не ты) будут говорить, что линукс – не десктопная ОС. И на сей раз мне даже нечем будет им возразить!

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

А вот теперь подумай: вейландовский подход «это не задача графического сервера, этим должны заниматься тулкиты» по отношению к очень многим вещам эту ситуацию побеждает или, наоборот, усугубляет?

То есть 3 Мб вместо 2?

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

На макбуке.

Тогда уж скорее полезнее было бы, если бы сдох Qt)

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

Чего стоит только параллельное существование двух (на самом деле трёх) тулкитов в одном фреймворке: Qt Widgets и Qt Controls 2 на QtQuick

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

Сторонники Wayland постоянно употребляют «кейлоггер» в качестве ругательного слова.

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

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

Именно внутри десктопа это почти бесполезно без обратной связи, потому что тычки будут производиться по пикселям, а не по объектам. Более того, практически не нужно в линуксе, учитывая развитую экосистему CLI-приложений. В тот момент, когда тебе нужна такого рода автоматизация - уже проще написать скрипт.

На винде AutoIt существует из-за того, что вся винда построена вокруг гуев, и из-за убогости их CLI. Не надо тащить плохие виндовые практики на линукс.

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

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

И на сей раз мне даже нечем будет им возразить!

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

это не задача графического сервера, этим должны заниматься тулкиты

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

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

Совместить же в одном проекте настолько разные подходы к проектированию как интерфейсов

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

Это провал. У гнома много такого. Я думаю, что фидбек от других ux/ui-дизайнеров помог бы им стать лучше. Причем, кстати, это работает в обе стороны. У KDE тоже много странных элементов интерфейса, которые можно было бы улучшить, применив избранное из подхода гнома. Короче, при правильной игре выиграли бы все.

Qt Widgets и Qt Controls 2 на QtQuick

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

кинетическая прокрутка

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

не сделав полностью новый тулкит

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

Нет, потому что Qt, в отличие от GTK и сопутствующих велосипедов, является фреймворком с кучей модульных компонентов, а не ограниченным графическим тулкитом.

Нет, потому что GTK - часть большой экосистемы, которая основана на GLib. GTK сам по себе примерно соответствует QtWidgets, и аналоги других модулей Qt там, разумеется есть.

На Qt, в общем-то, то же самое

И близко нет. GObgect introspection позволяет с легкостью делать байндинги к другим языкам в полуавтоматическом режиме и с лёгкостью совмещать их в рамках одной экосистемы и даже приложения. А в Qt это делается ручками, в крови и слезах, вопреки, а не благодаря. Именно поэтому для GTK можно писать на каждом первом ЯП, даже на экзотике вроде D или Хаскелля (для ряда языков это вообще безальтернативный GUI-фреймворк), а байндинги к Qt взлетели только у Питона, и то периодически протухают.

У всех нормальных людей сделано поле для ввода имени файла, которое понимает в том числе полный путь

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

на которое никто не хочет переезжать.

Не не хочет, а не видит смысла, пока Gtk3 не EOL-нулось. Вспомни, что с Gtk2 -> Gtk3 было точно также. Для крупного проекта, у которого с разработчиками нормально, портануть на четвёрку - дело, ну, полугода плюс-минус.

И да, переезжают понемногу. Из относительно крупного переехал Inkscape, например.

Нет, потому что…

Да. Все компоненты Qt связаны и сопровождаются все вместе. Их API единообразен и структурирован. В случае «экосистемы glib» для всех сложных случаев, где требуется что-то более сложное, чем гуи. Берешь Qt - и всё, что тебе нужно, скорее всего будет из коробки. За примерами далеко ходить не надо: сериалпорт, MQTT, вебсокеты, аппаратные сенсоры и прочее, прочее.

GObgect introspection позволяет с легкостью делать байндинги

На это достоинства заканчиваются.

в Qt это делается ручками, в крови и слезах, вопреки, а не благодаря

Не настолько всё плохо.

Ты уверен, что виноват Гном или ГТК, а не создатели Гимпа

Взял гимп - ведет себя именно так. Взял инкскейп - поведение идентичное. Возможно, так себя ведет какой-то общий GTK-компонент.

те, кто его собирали в твоём дистрибутиве, что-то наколхозили?

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

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

Частично согласен. Там немного неочевидно, что логика такая же, как и в Наутилусе. Жмёшь ‘/’ и также доходишь или Ctrl+L и вставляешь свой путь.

Я же там же и написал: внедрением общих стандартов.

Ах, да. Вот на это опять забыл ответить. Да, я согласен, что это был бы наилучший подход. Но я не знаю, возможно ли это, учитывая, насколько гном замкнут сам в себе. Во времена Qt3 и GTK2 у нас была возможность конвертировать стили между библиотеками, был прекрасный QtCurve, но GTK от этого ушли.

Все компоненты Qt связаны и сопровождаются все вместе

Именно поэтому калькулятор на Qt тащит пол-КДЕ в систему по зависимостям? Достоинства-то будут?

Их API единообразен и структурирован.

А в GLib нет? Мне кажется, ты очень плохо себе представляешь эту экосистему.

Пипец, КАК я должен был об этом узнать? Но спасибо, буду пользоваться.

У них в какой-то момент была в интерфейсе галочка, которая включала ввод пути вместо кнопок, но они ее ВЫПИЛИЛИ. Видимо, опять «сложно для юзера».

При этом в KDE есть аналогичная функция, и они как-то ухитрились ее совместить: тыкаешь по кнопкам - навигируешься кнопками, тыкаешь правее (где курсор превращается в текстовый) - вводишь имя файла.

Вот это я и имею в виду, когда говорю, что гномовый UX/UI движется куда-то не туда.

Сейчас проверил - в Гимпе всё вставляется в диалоге открытия файла. Действительно, нет отдельной кнопки, чтобы редактировать адресную строку, но она открывается по Ctrl+l.

Именно поэтому калькулятор на Qt тащит пол-КДЕ в систему по зависимостям?

Это банально неправда.

А в GLib нет? Мне кажется, ты очень плохо себе представляешь эту экосистему.

Мне кажется, ты очень невнимательно прочитал сообщение, на которое отвечаешь.

Вот это я и имею в виду, когда говорю, что гномовый UX/UI движется куда-то не туда.

GIMP, кстати, на ГТК3. В ГТК4 в Гноме такого нет, так что движется он туда) Возможно, в ГТК3 их немного занесло

Не вставляется. Ни начиная со слеша, ни начиная с file:. Только если открыть ввод вручную, как товарищ выше посоветовал.

Пипец, КАК я должен был об этом узнать?

Ну вот такой-вот стандартный диалог открытия в Gtk3. Я так понимаю, UI затачивается, в том числе, на работу с клавиатуры и, видимо (это моё предположение) решили унифицировать с Наутилусом, где такое поведение и стандартный шоткат уже хренаста лет.

В Gtk4 уже поправили этот момент. Там можно просто тыкать в панель адреса (или тыкать по именам папок, это работает типа кнопок).

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

Во-первых, у GIMP свой диалог, хоть и основанный на GTK-шном (у которого, бесспорно, было множество проблем).

Во-вторых, я вот прямо сейчас запустил GIMP, открыл диалог открытия файла, нажал Ctrl+L (стандартная комбинация для ввода адреса почти везде), вставил путь к файлу и спокойно его открыл.

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

Я думаю, что фидбек от других ux/ui-дизайнеров помог бы им стать лучше. Причем, кстати, это работает в обе стороны. У KDE тоже много странных элементов интерфейса, которые можно было бы улучшить, применив избранное из подхода гнома. Короче, при правильной игре выиграли бы все.

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

Они по-разному работают и предназначены для разного

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

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

Увы, не работает с тачпадом.

Тем не менее, полностью новый тулкит в виде сначала GTK3, а теперь и GTK4 им в какой-то момент понадобился

Это всё равно что обозвать Qt6 полностью новым фреймворком в сравнении с Qt5.

GTK4 это не полностью новый тулкит, а новая версия того же тулкита. Для перехода на новую версию разработчикам не нужно полностью переписывать код отображения и взаимодействия с интерфейсом, в отличие от абсолютно разных Qt Widgets и QtQuick Controls.

Во-первых, у GIMP свой диалог, хоть и основанный на GTK-шном (у которого, бесспорно, было множество проблем).

Как тогда получилось, что у Inkscape диалог идентичен, и работает с идентичными проблемами?

нажал Ctrl+L

Веришь, или нет, но про Ctrl+L я узнал сейчас впервые %) Но даже если оставить это в стороне, то я в принципе не вижу в диалоге поля для ввода имени файла, оно появляется только после Ctrl+L. То есть, я активирую невидимый элемент интерфейса стандартным хоткеем. Нельзя так делать.

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

А как это работает, если я использую не гном? Фаллбечится на встроенный диалог GTK?

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

Если их сольют вместе внутри Qt, то проблема исчезнет сама собой.

Увы, не работает с тачпадом.

Как так? В доках указана поддежка тачпада.

Это всё равно что обозвать Qt6 полностью новым фреймворком в сравнении с Qt5.

Зато Qt4 был полностью новым по сравнению с Qt3. И переход с GTK2 на GTK3 был болезненным.

Как тогда получилось, что у Inkscape диалог идентичен, и работает с идентичными проблемами?

Inkscape не пользовался. Возможно, у него тоже свой, а возможно, чистый GTK-шный.

Впрочем, GTK-шный в обсуждаемом плане работает точно так же, поэтому не суть важно.

То есть, я активирую невидимый элемент интерфейса стандартным хоткеем. Нельзя так делать.

В данном случае соглашусь, что discoverability для такого стандартного элемента хромает. Пользователи GNOME, знакомые с этим поведением из Nautilus, проблем не испытают, но пользователи других окружений могут и не догадаться.

К счастью, этот диалог постепенно остаётся в прошлом.

А как это работает, если я использую не гном? Фаллбечится на встроенный диалог GTK?

Т.к. используется портал, то в условном KDE это будет файловый диалог KDE.

Если их сольют вместе внутри Qt, то проблема исчезнет сама собой.

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

А пока проблема таки есть.

Как так? В доках указана поддежка тачпада.

Увы, доки звездят.

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

Зато Qt4 был полностью новым по сравнению с Qt3. И переход с GTK2 на GTK3 был болезненным.

Но речь-то о GTK3 → GTK4, в котором не пришлось создавать новый API с нуля, чтобы запилить SceneGraph Kit.

для GTK можно писать на каждом первом ЯП, даже на экзотике вроде D или Хаскелля

Звучит круто, но толку мало. Что-то было на питоне, но зачахло. Стоило ли ради пары инвалидов с питоном городить весь этот огород?

Ты издеваешься, не иначе. Посмотри даже на официальный репо Гнома, там зоопарк языков, и всё это мирно уживается друг с другом: Vala, JavaScript, Rust, C, C++, Python, C#.

А «что-то было на питоне, но зачахло» по описанию больше на PyQt похоже)

Кроме гнома что-то есть? Да и зоопарк трудно назвать достижением. Если я захочу писать гуи на js, то сами понимаете куда мне идти (точно не в гтк). Моно не взлетело, писать на каком-то мёртвом D это совсем уж странно. Растишки тоже гтк не любят почему-то. Тем временем кдешники шпилят 30 лет на своих плюсах и горя не знают. Там дикие мысли писать гуи на хаскеле не приходят в голову. А вот когда на C пишешь гуи, то ещё как приходят. Потому что это нездоровая фигня.

Кроме гнома что-то есть? Да и зоопарк трудно назвать достижением.

Ну вот смотри, в чём прелесть идеи GIR. Есть у меня мой маленький проект (да, я его для себя и домашних делал и я им пользуюсь, не будем брать что-то прямо серьёзное и большое) и в нём есть управляющая библиотека, которая реализует набор классов GLib/GObject. Вот там в соседнем каталоге есть приложение на Vala (ну лень мне писать кучи ref/unref и т.д., почему-бы и не Vala), которое реализует управляющий клиент (на Gtk3). Пока экспериментировал - легко написал extension для GNOME на JS (оно мне не пригодилось, SNI прекрасно работает). Можно сделать какой-нибудь виджет для KDE на С++. Желающие, если они будут, могут накрутить чего-нибудь на Rust или Python. И это всё НЕ привлекая ручного труда по созданию биндингов (бесплатно). Красота-же, ну. Можно интегрироваться практически с чем угодно, имея только ОДНУ базу кода (ну, и более-менее адекватную классовую конструкцию).

Растишки тоже гтк не любят почему-то

До такой степени, что gtk-rs, на данный момент единственное (на мой взгляд), на чём можно запилить адекватный UI. Всё что на Pure Rust выглядит пока, как УГ, уж извиняюсь.

потому что, очевидно, идеи гнома им ближе, чем идеи KDE.

Вот мне ни капельки не очевидно. Разработчики иногда пилят софт на работе, потому что работодатель заинтересован в софте, а разработчики заинтересованы в оплате своего труда.

Кстати, что насчёт разработчиков KDE? Допустим, проект KDE внезапно закрылся, и по каким-то причинам его нельзя продолжить. Пойдут разработчики KDE пилить гном?

Т.е. реализация wayland это самопал, а реализация x11 (с кучей дыр), это универсально и корпоративно. А ты умный.

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

Увау. Чтобы фиксить код надо знать язык оказывается. Ещё и Раст это не си. Ты не шутишь часом?

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

чем он лучше Моцарта?

Разработчики иногда пилят софт на работе

Если ты хочешь рассматривать это в таком ключе, то всё становистя еще хуже: разработчики гнома вполне могли бы пилить KDE за деньги. Впрочем, как и наоборот.

Пойдут разработчики KDE пилить гном?

Я почти уверен, что они пойдут пилить что угодно еще, более идеологически-совместимое с бывшим KDE.

К счастью, этот диалог постепенно остаётся в прошлом.

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

У меня есть стойкое ощущение, что в гноме вопросами UX/UI занимаются люди, которые только думают, что понимают UX/UI. Отсюда весь этот псевдоюзероориентированный бред.

Т.к. используется портал, то в условном KDE это будет файловый диалог KDE.

Что-то не работает. Беглый гуглеж показывает, что это зависит от умений софта.

А пока проблема таки есть.

Видится мне, что исправят, когда проблема станет насущной.

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

In the future, we should handle native gesture events on every operating system that provides them (at least macOS, iOS and Windows), and thus the widget gesture framework will finally be obsolete, because it will no longer need to watch what multiple fingers are doing and interpret that on its own.

Но речь-то о GTK3 → GTK4

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

Красота-же, ну.

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

разработчики гнома вполне могли бы пилить KDE за деньги

Вот только платить им готовы за разработку Гнома, а за КДЕ не готовы. Ой, а как же так вышло?🤔

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

Radeon R3, GCN 2, DX12, oGL 4.6, vulkan 1.2, драйвер radeonsi, короче ничего такого что могли бы дропнуть по поддержке. Последний КДЕ из Арча, sddm, дефолтная конфигурация всей графики.

КДЕ Х11 просто не стартует с 6.1 до 6.5, на вайланде в 6.3-6.5 фризы и лаги при работе с окнами, рассыпающиеся текстуры рамки или самого окна, в 6.5 Хвайланд окна регулярно зависают и конкретно vivaldi получает рэндомные события от мыши. Эталонный глюкодром.

Это равносильно тому чтобы КДЕ умер в пользу гнома. Я не против чтобы умер конкретно гном, но всё остальное должно остаться и стать взимносовместимым, как это происходит в Х11. Свобода пользователя в настройки окружения растёт в квадрате от числа доступных ДЕ/ВМ.

Статистику в студию.

за КДЕ не готовы

Это заявление не соответствует действительности.

В логи-то смотрел? Или они у тебя отключены, как обычно? %)

Ладно, шутки в сторону:

рассыпающиеся текстуры рамки или самого окна

Так выглядят глюки 2D-ускорения на иксах. Вот буквально так. Я в позапрошлом году самолично такой баг подкостылил в одном драйвере на NetBSD.

Я понимаю, что чукча писатель, а не читатель. Но ты всё же попробуй осилить хотя бы краткое описание что такое Wayland.

всё остальное должно остаться и стать взимносовместимым

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

Свобода пользователя в настройки окружения растёт в квадрате от числа доступных ДЕ/ВМ.

А вместе с тем - бажность и сложность отладки всего этого. Комбинаторика так работает.

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

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

Что-то не работает. Беглый гуглеж показывает, что это зависит от умений софта.

В чём пробовал? Я установил Transmission, использующий GTK4, нажал на кнопку открытия файла — получил окно файлового диалога KDE. Да даже Celluloid — интерфейс над libmpv для GNOME, использующий libadwaita, — открывает KDE-шные диалоги.

Видится мне, что исправят, когда проблема станет насущной.

Проблемы не надо было допускать. Ведь оно не само насралось — добавить второй тулкит без замены старого было решением разработчиков Qt.

Как обычно делают: если появилась необходимость полностью переписать что-то, то выпускают новую мажорную версию, а старую реализацию или оставляют в старой версии, или создают прослойку, имплементирующую старые API, используя новую реализацию. А тут же одним техническим решением команда Qt породила проблему, от которой KDE страдает до сих пор, спустя больше чем 10 лет после выхода Qt5, и конца и края этому всё ещё не видно.

In the future, we should handle native gesture events on every operating system that provides them (at least macOS, iOS and Windows), and thus the widget gesture framework will finally be obsolete

А в итоге спустя 6 лет это прекрасное будущее всё ещё не наступило, и в KDE половина приложений (если не больше) всё так же не поддерживает кинетическую прокрутку на тачпаде. Даже откровенно некорректную документацию за 6 лет так и не поправили.

Тем временем в GTK кинетическая прокрутка работает с 2012 года.

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

Но ни одна мажорная версия GTK не содержала в себе до кучи старую реализацию рядом и отдельно от новой.