Solus отказывается от GTK

Читайте стандарт протокола Wayland до просветления. По сто раз объяснять одно и то же мне уже надоело. Всего хорошего.

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

Ага, и в итоге GNOME-разработчики сделали этот костыль, который делает… заголовок окна!

Да, он делает CSD. SSD реализовывать по-прежнему не обязательно, при этом те DE, которые хотя SSD, могут это сделать. Л — логика.

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

Так в чём проблема, порт на Qt4 у кикера есть со времён беты четверокед. Был бы нужен — допилили бы. Но не пригодился.
Вообще, единственное, в чём плазма по-прежнему уступает Кикеру — это умение в кастомизацию: типа там фон поменять, прозрачность настроить и т.п. — для всего этого изволь, значит, лезть в Карбон и редактировать тему. И это в кедах.
Впрочем, последний раз я этим занимался, когда перешёл на пятые кеды и меня бесила тень от панельки в свежем бризе и вообще хотелось сделать её попрозрачнее.
Хотя может я просто фартовый, раз у меня и плазма не падает, и гном, скотина, не тормозит. Только AMDGPU, зараза, портит всю малину своими глюками при гибернации.

Только AMDGPU, зараза, портит всю малину своими глюками при гибернации.

что еще за глюки?

Да там периодически появляются регрессии типа «black screen on resume». Вот недавно вылезла ещё одна такая, в 5.14 должны были пофиксить (судя по багзилле), жду пока оно мне в тестинг прилетит.

Та же Qt, ЕМНИП, продолжает работать через xcb по умолчанию, если используется сеанс GNOME на Wayland.

Нет, работает через QGnomePlatform (в Fedora точно).

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

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

Везде, кроме гнома, уже работает xdg-decoration. Какие у разработчиков гнома могут быть причины заставлять других всё переписывать специально ради них (что, в свою очередь, вызывает страдания пользователей, потому что сразу поддержка CSD в приложения добавлена не будет, а в некотрые она вообще никогда не будет добавлена), кроме как их непомерное ЧСВ и некомпетентность?

Что значит «продолжают», объяснять нужно?
Не согласовали SSD — должны продолжать использовать CSD.
Если приложение не согласовало использование SSD с композитором, но вместо рисования декораций на стороне клиента не рисует их вовсе, то оно сломано.

Опять отсебятина. Не согласовать использование SSD могут в двух случаях: 1) клиент хочет использовать CSD, 2) в композиторе не реализован протокол. В первом случае, он, конечно же, продолжит использовать CSD. А во втором случае ему просто ничего не остаётся, как continue to self-decorate as they see fit, т. е. «делай что хочешь». Это «as they see fit», которое ты решил опустить и не перевёл, включает всебя и то, что приложение может вообще ничего не рисовать.

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

Или хватит тупить и признаешь наконец, что задача, которую ты хотел поручить SSD или libsimplewindow.so - это идиотизм, борьба с ветряными мельницами? Ну а либдекор - это да, библиотечка, если кому-то нужно то что она делает, то на здоровье.

libdecor.so == libsimplewindow.so

Эта библиотека выполняет ровно то, что я хотел бы чтобы выполняла три года назад теоретическая несуществующая библиотека, а ты был сильно против такого подхода. А вот теперь, когда этот подход «из моих уст» реализовали разработчики GNOME – переобулся.

Знатоки гномофилософии, расскажите как такое получилось:

1. Есть расширения протокола вяленого, которое позволяют его юзать для десктопных задач.
2. Среди них есть расширение для сервер-сайд декораций. В старом иксовом мире это было поведение по-умолчанию, и разработчики привыкли, что это делают за них.
3. Гномеры решили, что правильный UX – это только клиентские декорации. И делают так свои приложения.
4. Для сторонних приложений, которые хотят просто какие-то «стандартные» декорации гномеры придумали специальную либу libdecor.

И вот главный вопрос: почему гномовский WM не может заюзать гномовский же libdecor для того чтобы рисовать приложениям хоть какие-то декорации на стороне сервера? Почему так принципиально чтобы их именно клиент рисовал? Всё равно же будет выглядеть не по гномовским гайдлайнам.

Вроде это самый оптимальный вариант: разработчикам приложений не надо ничего переделывать в своём софте, а гномеры получают то самое поведение, которое они придумали в libdecor. И волки сыты, и овцы целы.

А что за карта?

SSD нужен как минимум для тайловых WM, в которых гномовские HeaderBar’ы занимают нереально много места и в принципе бесполезны.

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

Вообще странная логика: испортить всем чтоб 1% пользующихся тайловыми WM смогли отключить хедербар, врубить глобальное меню и тем самым получить ту же экономию места, которую CSD даёт всем из коробки. Может вместо костылей из говна и палок просто отправить SSD на помойку? И пускай разработчики за пару лет запилят нормальные функциональные CSD, без оглядки на гуи 80х годов.

Но проблема в том, что сама сущность CSD в Linux абсолютно никак не стандартизирована, у каждого свои костыли. В Гномовских прогах - это неотключаемый заголовок

Это часть более широкой «проблемы»: отсутствия единого стандартного тулкита. Если для тебя это реально проблема, то решается просто: выбери один крупный ДЕ и пользуйся только им, получишь и одинаковые кнопки, и одинаковые заголовки и одинаковое поведение окон. Или смирись с сосуществованием немного отличающихся заголовков, тулкитов и HIG.

Вообще, удивительно то, что на всём протяжении существования гуёв в ПК куча программ реализовывали CSD и были самыми крутыми, образцами для подражания. Никого от них не ломало, качали шкурки для винампа, не парились что кнопки мелкие. Какую только чушь не делали, помнится была софтина, вроде из нортонутилит, которая эмулировала стандартное виндовое окно, но была в форме щита. Ставила регион на окно и сверху рисовала неровный заголовок цветом темы из винды и кнопки стандартные туда же. Майкрософт вон риббон придумали, тоже люди пользуются, причём люди не с линупса, непривычные к сосуществованию Motif/Qt/GTK/Vx. Но когда вместо вырвиглазных шкурок и окон сложной формы людям предложили обычные, нормальные тулкиты, только без пустого заголовка, как вдруг сразу стало неудобно.

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

А потом все округляют глаза, хватаются за головы и создают очередную 10500 тему на ЛОРе о том, почему Linux на Desktop’е это 1%

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

Я бы сказал, что SSD не нужен нигде и никогда

Разрабы гнума через 3 гоода запиливают SSD.

Крендель: да я всегда так считал.

А потом все округляют глаза, хватаются за головы и создают очередную 10500 тему на ЛОРе о том, почему Linux на Desktop’е это 1%

Совсем не поэтому.

Да, он делает CSD.

Он делает заголовок окна, который ты объявил устаревшим.

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

Не будет. Это ОПЦИОНАЛЬНОЕ расширение. Поэтому с точки зрения протокола, всё реализовано правильно.

Пинать надо авторов wayland-protocol, чтобы стандарт шёл в core и стал обязательным, если уж он так нужен.

Вроде бы AP выдвигал тезис (с которым я согласен), что wayland нужен авторитетнй руководитель, который треснет кое-чем по столу и скажет «будет так». Ну а пока классическое базарное «однажды лебедь раком щуку» aka базу кое как утрясли, по остальному сто лет будем лаятся.

Когда пользователи запускают свои любимые игры и какой-нибудь MPV в GNOME под Wayland’ом и видят это безобразие с заголовками окон, то 1% начинает истощаться.

Гном: Ну, это, чувак... https://i.imgur.com/KvFPgFx.png

Знаешь, давно хотел сказать к вопросу о твиктуле.
В Friends был эпизод, когда тамошняя перфекционистка Моника устроила уборку в квартире, чтобы было красиво и ничего лишнего и глаз радовался. Но ведь выкинуть всё тоже нельзя, в этой квартире же ещё жить.
В итоге у неё получилась очень красивая и чистая квартира и адовый бардак в кладовке, куда попали в том числе и довольно нужные вещи.
Вот я когда, пардон, «твикал» гном, чтобы элементарно настроить раскладки, их переключение и compose, сразу вспомнил этот эпизод. Впрочем, хоть не через dconf и на том спасибо.
YMMV и всё такое.

RX570.

Это ОПЦИОНАЛЬНОЕ расширение. Поэтому с точки зрения протокола, всё реализовано правильно.

Расширения для поддержки методов ввода, вставки колёсиком мыши и т. д. тоже опциональные.

Не будет. Это ОПЦИОНАЛЬНОЕ расширение

Вроде вяленый сам по себе не про десктоп, а про терминалы оплаты, всякие мобильные устройства и кофеварки :)

Полноценный десктопный композитор, видимо, должен поддерживать всё xdg-барахло.

Пинать надо авторов wayland-protocol, чтобы стандарт шёл в core и стал обязательным, если уж он так нужен.

Зачем декорации окна, например, смартфонам, которые тоже реализуют у себя этот протокол? Нет, всё правильно что в базовом протоколе Wayland нет декораций, но эти опциональные расширения обязаны быть если на базе Wayland разрабатывается десктопная оболочка, а не планшетно-мобильная.

Пинать надо именно разработчиков GNOME, чтобы они решали эту проблему у себя. А каким образом решали – как в KDE с помощью поддержки этого опционального протокола или с помощью мольбы и хождения по багтрекерам графических тулкитов с целью продвижения в них libdecor’а – это уже их проблемы.

Ну вот тут все хотят как WinAPI, ну давай как WinAPI - все гномы от 1.0 до 4.1 и последущие впихнём и обмажем горой обвязки, чтоб оно как-то сосуществовало. Вот цэ гарно - будет почти как WinAPI.

А потом все округляют глаза, хватаются за головы

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

Лучший интерфейс - это командная строка. Аминь.

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

Лучший интерфейс — это телепатия

Эта библиотека выполняет ровно то, что я хотел бы чтобы выполняла три года назад теоретическая несуществующая библиотека, а ты был сильно против такого подхода. А вот теперь, когда этот подход «из моих уст» реализовали разработчики GNOME – переобулся.

Ну может я чего-то из твоих хотелок не понимал, но «сильно против» я не был, нечего выдумывать. libsimplewindow.so была уже тогда, называлась GTK, и как раз от разработчиков гнома. Кто хотел тот пользовался. Ну вот сейчас запилили вариант попроще, назвали libdecor. Но в общем и сейчас я то же самое утверждаю: libdecor нафиг не нужна. Управление в вейланде довольно простое, а библиотек для рисования овердофига, в таких условиях либа для CSD будет наполовину биндингом к протоколу, а наполовину - простеньким рисованием, которое притянет ещё с собой какую-нибудь cairo, которая не факт что в данной программе используется. Вот против чего я был и есть сильно против - это чтоб кто-то пилил библиотеку, которая цепляла бы SSD когда может, а когда не может - пыталась бы эмулировать заголовки из запущенного в данный момент DE, с поддержкой тем.

Даже во втором Андроиде есть поддержка мышки.

Но для десктопа они нужны. Как и xdg-decoration.

Крендель: да я всегда так считал.

Поменьше слушай EXL. Он какую-то хрень выдумал и теперь вот выдумал, будто эта хрень сбылась.

И вот главный вопрос: почему гномовский WM не может заюзать гномовский же libdecor для того чтобы рисовать приложениям хоть какие-то декорации на стороне сервера? Почему так принципиально чтобы их именно клиент рисовал? Всё равно же будет выглядеть не по гномовским гайдлайнам.

Вроде это самый оптимальный вариант: разработчикам приложений не надо ничего переделывать в своём софте, а гномеры получают то самое поведение, которое они придумали в libdecor. И волки сыты, и овцы целы.

Вот то, что ты сейчас тут говоришь очень не нравится Matthias’у Clasen’у, больше такое не говори и пофикси там своё приложение, прилепи к нему сверху полоску с надписью:

«Matthias Clasen ❤️ 🏳️‍🌈 [✖]»

И чтобы когда в центр крестика нажимаешь окошко закрывалось, ок?

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

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

С точки зрения протокола они не обязаны её решать.

Простите, а что они делают? Мобильный интерфейс или десктопный? Нахрена тогда GNOME-разработчики запилили всякие опциональные расширения вроде вставки текста по колёсику мышки из мира X11? С точки зрения протокола они не обязаны эту херню реализовывать вообще. Я сильно против этого расширения, например. Оно мешает мне и иногда портит тексты и исходники, так как я использую эмуляцию нажатия колёсика на тачпаде.

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

Они и решили. В итоге получилось это:

https://gitlab.gnome.org/GNOME/mutter/uploads/b706e4893efd048fdb77e32c6f64ae36/Снимок_экрана_от_2017-12-16_11-04-00.png

И вот это:

https://baat.z-lab.me/~exl_lab/screens/GNOME3_wayland_mpv_fuckup.png

Удобоваримо?

Пинать надо именно разработчиков GNOME, чтобы они решали эту проблему у себя. А каким образом решали – как в KDE с помощью поддержки этого опционального протокола или с помощью мольбы и хождения по багтрекерам графических тулкитов с целью продвижения в них libdecor’а – это уже их проблемы.

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

CSD-инициатива предполагала самостоятельную реализацию декораций средствами тулкитов, что собственно и сделано в GTK/Qt. Никакого либдекора там нет. Про либдекор речь вообще изначально заходила в смысле «ну может кто запилит какую-нибудь минимальную реализацию декораций в библиотеку, для инвалидов, не пользующихся тулкитами». SDL с либдекором на самом деле скорее плохо, в идеале SDL мог бы сделать что-то специфичное для игр, чтоб в случае работы в оконном режиме декорации повторяли стиль данной игры.

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

С декорациями всё равно придётся делать так, чтобы на планшете их гарантированно не было, а не через libdecor колхозить что-то. Т.е. всё равно придётся делать какое-то поведение специально для планшета.

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

В чем проблема с SSD и CSD!?

В идеальном мире все должно происходить так:

По дефолту всегда SSD. Приложение запускается и спрашивает у сервера можно ли ему юзать CSD, если да, то рисует, если нет, то работает по старинке. Если в среде отключено CSD, то его никто и не увидит. Хейта будет НОЛЬ. В чем проблема сделать fallback SSD интерфейс!? Вот как в foliate: CSD, SSD. Вот с*ка я понять не могу, В ЧЕМ ЗДЕСЬ ЭКЗИСТЕНЦИАЛЬНАЯ ПРОБЛЕМА!? Сложно одно меню-бар сделать для ретроградов?! В чем смысл всех этих танцев, если можно сделать как для людей, а не как для дебилов?

чтобы стандарт шёл в core

В core минимум весь wlroots втащить надо.

CSD-инициатива предполагала самостоятельную реализацию декораций средствами тулкитов, что собственно и сделано в GTK/Qt. Никакого либдекора там нет.

Ничего там не сделано в Qt кроме кривого CSD никак не вписывающегося в тему GNOME. Никто на эту инициативу тупо не откликнулся.

GNOME-разработчикам пришлось самим брать в руки компилятор и писать «libdecor» для Qt, вот он:

https://github.com/FedoraQt/QGnomePlatform

При этом есть подозрение, что этот костыль тоже скоро будет зависеть от libdecor.so: https://github.com/FedoraQt/QGnomePlatform/issues/15#issuecomment-886247574

Такие вот дела.

Поменьше слушай EXL. Он какую-то хрень выдумал и теперь вот выдумал, будто эта хрень сбылась.

Ну сбылась же, libdecor.so появился? Появился. Написали его не какие-то там васяны, а сами разработчики GNOME? Да. В SDL2 его запихали? Запихали. Шах и мат, я «Ванга».

Удобоваримо?

Терпимо.

Хотя смысл CSD совершенно правильно написали ниже. Смысл был в том, чтобы шапку рисовал тулкит, а не каждый сам своё колхозил. А libdecor сделали для отдельных «нетаких как все», которе тулкитами не пользуются.

И вот главный вопрос: почему гномовский WM не может заюзать гномовский же libdecor для того чтобы рисовать приложениям хоть какие-то декорации на стороне сервера? Почему так принципиально чтобы их именно клиент рисовал? Всё равно же будет выглядеть не по гномовским гайдлайнам.

Они это объяснили в доке. SSD - это плохо. Его не должно быть.

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

Гномовские хедербары не занимают никакого лишнего места

В том и дело что место они занимают, а не экономят.

Вообще странная логика: испортить всем чтоб 1% пользующихся тайловыми WM смогли отключить хедербар, врубить глобальное меню и тем самым получить ту же экономию места, которую CSD даёт всем из коробки. Может вместо костылей из говна и палок просто отправить SSD на помойку? И пускай разработчики за пару лет запилят нормальные функциональные CSD, без оглядки на гуи 80х годов.

Я тебе открою один секрет - ты путаешь тёплое с мягким. А именно CSD и их гномовскую имплементацию - GtkHeaderBar. Взгляни на тот же GNOME Terminal до 3.38. Обычная рамка и классический тулбар. Но прикол в том, что рамка рисовалась окном, а не Mutter'ом. Под Wayland точно. Может CSD в определенной степени и неплох, но только не в том виде, в каком он представлен в GNOME. Что касается тайлинга - я привёл его как пример. И пример, я считаю, хорошего удобного рабочего окружения. А ты уже передергивать начинаешь.

Так я о чём и говорю, что поскольку протокол опциональный программист (тулкит?) должен предусмотреть, что его ВНЕЗАПНО может и не оказаться. Но как всегда спеки читаны жопой и делать всё лень.

Смысл бл в том, чтобы шапку рисовал тулкит, а не каждый сам своё колхозил.

Так и наколхозили в тулкитах. Каждый своё на отвались, чтобы было вот это самое «терпимо». Ты думаешь кто-то из разработчиков тулкитов будет там отслеживать а какой в GNOME и KDE дизайн в этом месяце? Если бы я был разработчиком тулкита, я бы не стал. Вот и они не стали, а сгенерировали кривые заглушки через которые даже окно ресайзить больно, не то что манипулировать им.

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

Зачем вообще программе запрашивать SSD, если у неё есть «хороший и удобный CSD»?

Если вариант зависит от предпочтений пользователя, то у него и надо это всё спрашивать (это может быть настройка, переменная среды, параметр запуска, что угодно).

Ничего там не сделано в Qt кроме кривого CSD никак не вписывающегося в тему GNOME.

Чувак, вот сколько раз тебе нужно объяснить, что «вписываться в тему» вообще никто не предлагает? Не нужно это. Совсем. Пусть Qt вписывается в тему Qt, большего от него никто не просит.

Ну сбылась же, libdecor.so появился? Появился. Написали его не какие-то там васяны, а сами разработчики GNOME? Да.

Ну знаешь, вон недавно новость была про то что в KDE появилась возможность сворачивать меню в «гамбургер». Мне тоже начинать рассказывать про то что KDE вот-вот перейдёт на CSD? Ещё раз: libdecor - это просто либа для совсем ленивых, не более того. Это не биндинг к гному. Просто запилили чтоб не воняли.

Лучший интерфейс — это телепатия

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

Чувак, вот сколько раз тебе нужно объяснить, что «вписываться в тему» вообще никто не предлагает? Не нужно это. Совсем. Пусть Qt вписывается в тему Qt, большего от него никто не просит.

Qt нормально не работает в GNOME из-за груды всех этих костылей. libdecor и QGnomePlatform это не только «няшный GNOME’овский заголовок окна», но и клиентские имплементации перемещения и ресайза окна. Тени. Глючные до нельзя. А в Mutter/X11 – нормальные. И в KWin/Wayland – нормальные (там кстати наверняка CSD, а не SSD у Qt-приложений).

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

это как специально расшибить себе голову дверь (или не себе) потому что в инструкции к двери не написано чётко что этого делать нельзя.

Зачем вообще программе запрашивать SSD, если у неё есть «хороший и удобный CSD»?

Потому что придёт sunderland93 в багтрекер, покажет https://gitlab.gnome.org/GNOME/mutter/uploads/b706e4893efd048fdb77e32c6f64ae36/%D0%A1%D0%BD%D0%B8%D0%BC%D0%BE%D0%BA_%D1%8D%D0%BA%D1%80%D0%B0%D0%BD%D0%B0_%D0%BE%D1%82_2017-12-16_11-04-00.png и попросит юзать SSD, чтоб все заголовки были одинаковыми.

Если вариант зависит от предпочтений пользователя, то у него и надо это всё спрашивать (это может быть настройка, переменная среды, параметр запуска, что угодно).

Это неправильно. Откуда мне, пользователю, знать, хороший у данной программы CSD или не очень? Я уж не говорю о том, что лазить в настройки лень. А разработчику не узнать, насколько хорош SSD, может там наколхозили в заголовке 100500 просто необходимых для работы кнопок, и включив CSD он их пользователя лишит. Да и программисту 2 лэйаута гуйни под разные варианты зачем тянуть?

Нет, вменяемое решение только одно: CSD. Пусть разработчики DE знают, что никаких костылей в виде особых кнопок в заголовках нет. Пусть разработчик софта решает, хочет он пилить свой красивый и функциональный заголовок или возьмёт дефолтный из тулкита. Ну, или если тулкита нет, пусть берёт libdecor.