LINUX.ORG.RU

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

 , , ,


3

2

Один из лидеров проекта Solus Linux, Джошуа Стробл (Joshua Strobl), объявил о намерении отказаться от GTK при разработке как будущих версий Budgie, так и всей экосистемы приложений в Solus. В своем блоге он высказал ряд упреков в адрес текущего состояния и планов развития GTK, а также философии разработки GNOME.

По его словам, повсеместное насаждение Adwaita как единственно верной темы рабочего стола и попутное удаление части API для разного рода кастомизации добавило головной боли разработчикам, поддерживающим стек GNOME в дистрибутивах или интегрирующим в него свои приложения. Все предлагаемые варианты настройки внешнего вида приложений на базе GTK и сопутствующих библиотек отклоняются, а участники команды GNOME в ответ грубят в тикетах и соцсетях.

Жалуется Джошуа и на то, что выпущенный чуть менее года назад GTK 4 немного усложнил код для работы с виджетами, запретив прямое наследование. Но гораздо более важной проблемой ему видится упразднение API X11, в частности для получения конфигурации подключенных мониторов. Двигаясь в сторону полной поддержки Wayland, GNOME удалил функции опроса X-сервера, поручая разработчику писать собственные интерфейсы для обращения напрямую к X11 (либо к API других ОС, если приложение оказалось кроссплатформенным).

В то время как рабочая функциональность удаляется, многие известные ошибки в GNOME не исправляются месяцами и годами (в частности, автор приводит в пример ошибки с прокруткой в GtkListView и с переключением на другое окно при открытом выпающем списке в GtkPopover). При этом Джошуа описывает это в разрезе собственного опыта написания с использованием GTK своего аудиоплеера Koto.

Релиз GTK 4 не оправдал ожидания авторов Solus, надеявшихся на ряд обещаемых изменений в libhandy, которые в итоге так и не были добавлены. А дорожная карта к GTK 5 предрекает ещё большее закручивание гаек в части кастомизации и общий регресс как в UX, так и для использования библиотки в сторонних приложениях. Джошуа прямым текстом утверждает, что использование в разработке GTK 4 и выше — это выстрел себе в ногу.

По итогам этих размышлений лидеры проекта Solus приняли решение отказаться от использования GTK в Budgie и в целом минимизировать присутствие GNOME в своем пользовательском окружении, перейдя к выбору одного из следующих GUI-тулкитов:

  • EFL (библиотека в основе Enlightment Desktop);

  • Qt;

  • iced (кроссплатформенная GUI-библиотека для Rust).

В случае Qt разработчикам Solus не хочется писать код на C++, и к тому же смущает «коммерческая лицензия» Qt и неприятный осадок. iced находится в ранней стадии разработки и многие полезные вещи придется писать с нуля, а ресурсов для этого нет.

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

Что касается дистрибутива, то версия с GNOME будет собираться в отдельный образ, и ей будет уделен минимум внимания, будет обеспечена лишь базовая работоспособность. В Budgie 11 не будет никаких зависимостей от GTK.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: sudopacman (всего исправлений: 9)

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

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

В fltk нет и не предвидится поддержки Wayland.

А зачем вяленый вообще нужен? Его уже десятилетие разрабатывает, а он всё ещё считай нихрена не умеет.

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

А зачем вяленый вообще нужен? Его уже десятилетие разрабатывает, а он всё ещё считай нихрена не умеет.

Это же ПРОТОКОЛ!

Как он сидеть может?
anonymous
()
Ответ на: комментарий от Rootlexx

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

Без xdg-decoration (или эквивалентного протокола) невозможно реализовать поддержку SSD. Это важная функциональность.

Наглое враньё это лишь в вашей голове.

То есть утверждение «если бы разработчики гнома добавили поддержку xdg-decoration, то разработчикам сторонних десктопных приложений, использующих SSD, не пришлось ничего переписывать для поддержки одного лишь гнома» — ложь?

А это вам нужно доказать.

Приложения годами использовали SSD. Под Wayland для них сделали стандарт xdg-decoration, который работает в основных его реализациях. В чём уважительная причина отказать в реализации данного стандарта? «Мы не хотим, поэтому вы обязаны добавить поддержку CSD специально для нашего композитора» — это не уважительная причина.

должно делать
должно рисовать
требованию наличия декораций

Не должно. /thread

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

Понимаешь что тебе сейчас заимеют мозг «сетевой прозрачностью»?

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

Это слишком много. Нужно до пяти успеть, а потом в отпуск.

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

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

У меня для тебя новость года так с 1995го, ну может с 2000го: единого стиля приложений на разных тулкитах не будет никогда. Проблема неразрешима принципиально. Слава богу, после закапывания X11 и XDG-decorations у тебя появится единый стиль в рамках одного окна, когда заголовок будет соответствовать другим элементам. Если для тебя единый стиль важен - ты должен начинать топить за CSD.

У оконного менеджера практически не будет контроля над окном (да да, если CSD приложение повиснет - хер ты его с места сдвинешь).

Это совершенно мизерная проблема. Отправишь его в фон и всего делов.

EXLвсё правильно сказал насчёт политических причин не реализовывать SSD для Mutter.

Неверно. Это я правильно объяснил причины не реализовывать SSD для Mutter: Solus отказывается от GTK (комментарий)

Без всяких политических игр и заговора жидомасонов.

Самое адекватное - это Dynamic Window Decorations, и хотя дальше концепта идея не ушла - KDEшники сейчас активно реализуют некоторые его идеи

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

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

Без xdg-decoration (или эквивалентного протокола) невозможно реализовать поддержку SSD. Это важная функциональность.

А вот гномеры считают, что SSD - не только неважная, но и вредная фича.

То есть утверждение «если бы разработчики гнома добавили поддержку xdg-decoration, то разработчикам сторонних десктопных приложений, использующих SSD, не пришлось ничего переписывать для поддержки одного лишь гнома» — ложь?

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

Приложения годами использовали SSD.

Ты хотел написать «годами использовали x11»? Да. И сейчас используют. До вейланд-онли лет 10 ещё наверное. Успеют приспособиться. SSD вообще самая мелкая проблема этого перехода, захват экрана, глобальные хоткеи, вот это важно.

Не должно.

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

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

А вот гномеры считают, что SSD - не только неважная, но и вредная фича.

Вредная для кого?

Конечно ложь. Им придётся переписывать всё под Wayland.

Они уже переписали.

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

Если для тебя единый стиль важен - ты должен начинать топить за CSD.

За CSD в чём? В Гноме? Ты посмотри хотя бы как выглядит CSD в гноме/GTK, и как он выглядит в Qt. Это дикий оверхед - рисовать то, что может предоставить композитор. Не будет никакого единого стиля если повсеместно будет CSD, выброси уже из головы эту глупость, навеянную и навязанную разрабами Гнома. Я считаю, что раз CSD в том или ином виде есть в тулките, то он должен использоваься как fallback, тогда когда композитор настолько убог, что не в состоянии дать приложению заголовок. Но никак не в качестве обязательно опции.

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

Я могу понять про тон (там, где это действительно проблема), я не очень понимаю про «игнорирование конструктивной критики». У софта прямо в лицензии понятными латинскими буквами написано: «НИКАКИХ ОБЯЗАТЕЛЬСТВ».

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

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

Поэтому по содержанию (не по форме) @bernd абсолютно прав. Не нравится – дверь вон там. Можно на выходе прихватить с собой клон репозитория и сделать по-своему. Можно ничего не прихватывать и найти другое решение — а там уж история рассудит, кто прав, а кто идиот.

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

Ок, приведу твою цитату:

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

Дело не в том чтобы каждое приложение имело по два варианта, для CSD и SSD, а в том, что если интерфейс приложения построен на обычном тулбаре и рамке окна - дать ему возможность отрисовать эту рамку. И всё. CSD приложения Гнома прекрасно работают в KDE, наследуют настройки оформления, шрифты и даже расположение кнопок (внезапно да?). Так почему приложения Qt/KDE не могут также нормально работать в GNOME? Ответ прост - потому что гномеры живут в своём манямирке, в котором есть только GTK а Wayland требует наличия клиентских декораций.

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

можно сказать «существует множество других DE, которые вы можете установить, если вас не устраивает предлагаемый нами»

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

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

Если для тебя единый стиль важен - ты должен начинать топить за CSD.

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

CSD - это мобилки.

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

И ещё: CSD в гноме построены с использованием кастомного протокола __GTK_FRAME_EXTENTS. И само собой никто не будет его добавлять в Qt и остальное, в Kwin его добавили только ради лучшей работы и лучшего внешнего вида CSD приложений GNOME. Потому что разрабам KDE не плевать на пользователей и они не пытаются делать из них тулкитофобов. Реализуй гномеры инициативу CSD нормально, согласовав со всеми ключевыми разработчиками рабочих столов - негатива было бы меньше.

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

Ну да, заголовков нет в SDL и Qt, а библиотеку libdecor в итоге написали в Gnome.

Всё так. Никто особо не поддержал радужную инициативу GNOME-разработчиков «а давайте все перейдём на CSD», им пришлось самостоятельно создавать QGnomePlatform и libdecor, чтобы пытаться исправить то, что по дефолту наколхозили разработчики АБСОЛЮТНО ВСЕХ тулкитов отличных от GTK.

Шесть лет они пытаются решить проблему, которую создали на ровном месте. Когда можно было бы просто подцепить эту libdecor к Mutter и выводить нормальный по дизайну, HIG’у и поведению (ресайз, перемещение, тени и пр.) заголовок окна и декорации у тех приложений, которые в Wayland реализуют лишь контекст окна и рисуют кривые декорации-заглушки сделанные абы как for testing purposes.

Кстати, а не в Gnome на Wayland сеансе как?

В KDE запилили xdg-decoration и те тулкиты и приложения, которые не реализуют CSD (а их превалирующее большинство) просто используют системный заголовок с понятным и адекватным UX/UI, а не заглушки сделанные на отвались, как в GNOME.

3 года назад лично сам Ryan C. Gordon (он же icculus) запилил это в SDL для KDE: https://www.youtube.com/watch?v=f6ONONo2C1c

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

А она уже есть, анон. X11 + CDE + Motif. Единая, одобренная отцами UNIX.

Какую вульгарную проприетарщину ты перечислил. Фу.

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

Ну, собственно вот так эта libdecor решает проблему с отсутствием заголовка https://imgur.com/a/LhOux5r

P.S. khrundel чё ты там говорил насчёт общего стиля в случае CSD? Вот такого как на скриншоте? Да в гробу я такой «общий стиль» видел. Как и все адекватные люди.

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

Т.е по твоей логике вообще бессмысленно кого-либо критиковать? Только потому что он может заявить «дверь вон там»? Ну знаешь ли, в таком случае есть риск остаться в полном одиночестве, потому что разбегутся все. И в этой теме на протяжении 15 страниц мы как раз обсуждаем то что нельзя так делать. Нельзя не прислушиваться к мнению сообщества и посылать его при любом удобном случае. Именно это и делают и разработчики GNOME, и Solus.

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

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

Хорошо бы всю критику обобщить в виде тезис, а ниже объяснение почему …
Ведь далеко не все знают почему разработчики GNOME приняли то или иное решение.
Кроме этого, такой документ помог бы тем, кто решил бы принять участие в разработке оконной подсистемы.
Ныне ее похоже нет.
Есть какие-то проектные решения и всякие костыли.
В результате имеем БОЛЬНОЙ и ХРОМОЙ проект, который доктора не лечат, а … /сами знаете/

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

Если с такими НЕНУЖНО и РАБОТАТЬ В НАШЕМ DE - БОЛЬШАЯ ЧЕСТЬ, РАЗРАБОТЧИКИ ПРИЛОЖЕНИЙ ДОЛЖНЫ ПРИЛОЖИТЬ УСИЛИЯ бегали чуваки из suckless, никто бы и бровью не повел. Не нравится - установи другое, это для пользователя, а разрабу ПО нужно спецом гном учитывать? Понятно, что с гноморазрабами спорить непродуктивно, лучше направить усилия на изменение политики debian по дефолтному DE, но все же.

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

Дело не в том чтобы каждое приложение имело по два варианта, для CSD и SSD, а в том, что если интерфейс приложения построен на обычном тулбаре и рамке окна - дать ему возможность отрисовать эту рамку. И всё.

Вот, самый правильный вывод. Многие ведь далеко не против концепции CSD там, где это действительно оправдано. Я, например, нахожу реализацию CSD в Firefox и Chrome с табами в заголовке окна весьма удобной и сильно экономящей вертикальное пространство.

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

Ответ прост - потому что гномеры живут в своём манямирке, в котором есть только GTK а Wayland требует наличия клиентских декораций.

Именно так, это манямирок даже не разработчиков, а дизайнеров GNOME с фантазиями вроде «а давайте сделаем революцию в мире UI: Let’s get rid of title bars!!!». Это действительно можно сделать, когда у тебя из приложения только браузер и калькулятор.

У GNOME (и у любого Linux-окружения) нет абсолютно никакого веса, чтобы диктовать разработчикам кроссплатформенных тулкитов то, что и как именно они должны делать. Они не Apple, которому стоит лишь заявить о намерениях удаления 64-битных бибилиотек и переходе на ARM и вот уже армия разработчиков и даже такие гиганты как Adobe бегут роняя кал переписывать и адаптировать свои приложения, а Linux-разработчики выстраиваются в очередь чтобы портировать Linux на новый Macbook.

Никто и никогда из разработчиков тулкитов нормально не будет реализовывать все эти вещи на клиентах в соответствии с хотелками и влажными мечтами дизайнеров GNOME в своих бложиках. И этот факт отчётливо виден по проишествии шести лет на примере с SDL2, MPV и Qt и кучи других библиотек и тулкитов, которые заявили о своей поддержке Wayland несмотря на стенания Matthias’a «Fix the applications first» Classen’а. Они просто на отвались забили всё криво работающими CSD-заглушками, либо вообще забили.

О чём может идти речь, если даже сами GNOME-разработчики, которые поняли что их идею восприняли примерно никак, самостоятельно запилили QGnomePlatform, но не смогли там сделать тот же UX/UI у Qt-приложений который у них имеется на Mutter/X11 с SSD. Банальный ресайз окна под QGnomePlatform – боль, потому что границы окна на клиенте выверяются чёрти как. По этой же причине перемещение окна при удержании заголовка и движениях мыши хаотично скачет. У окна нет теней, кнопки в заголовке окна работают без анимаций и т. д.

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

Это политическое решение GNOME с Mutter огромным якорем тормозит распространение и поддержку Wayland в Linux-окружениях.

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

Ох лол, я думал они там нормально и по HIG’у сделали. А они сделали какую-то хрень. Может там как-то GNOME’овскую Adwaita всё-таки можно натянуть? Чем они вообще тогда 6 лет занимаются? Они абсолютно никак не решили эту чёртову проблему.

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

Я пока особо не вникал, только запустил демку. Под гномом она выдает то, что на скриншоте. В KDE - обычную кдешную системную рамку, благодаря поддержке......xdg-decoration внутри самой libdecor!

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

Без xdg-decoration (или эквивалентного протокола) невозможно реализовать поддержку SSD. Это важная функциональность.

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

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

То есть утверждение «если бы разработчики гнома добавили поддержку xdg-decoration, то разработчикам сторонних десктопных приложений, использующих SSD, не пришлось ничего переписывать для поддержки одного лишь гнома» — ложь?

А причём здесь данное утверждение, если вы назвали наглым враньём совсем другое, а именно:

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

Почему нужно, я объяснил, — ибо существуют композиторы без поддержки xdg-decoration (поскольку его поддержка опциональна), а значит, для них необходимо рисовать декорации на стороне клиента, если приложение хочет иметь декорации, — но вы это упорно игнорируете.

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

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

Не должно. /thread

Потому что вы так сказали? На такое может быть лишь один ответ:

Должно. /thread

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

Так почему приложения Qt/KDE не могут также нормально работать в GNOME? Ответ прост - потому что гномеры живут в своём манямирке, в котором есть только GTK а Wayland требует наличия клиентских декораций.

Нет, потому что QGnomePlatform не допилен пока что.

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

А шо так? Икаса снова патчи не завез?

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

До вас до сих пор не дошло, какую же чушь вы несли, и поэтому вы всё ещё свято уверены в своей правоте — вы даже не представляете, насколько это смешно читать каждый раз!

Но вы продолжайте, пожалуйста, не останавливайтесь: ведь чем глупее вы выглядите, тем мне лучше!

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

Ну так сделай меня не глупым. Ответь на вопрос! Всего делов… Вместо этого как барышня филейной частью только виляешь.

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

Т.е по твоей логике вообще бессмысленно кого-либо критиковать?

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

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

Совершенно верно. Но это не твой риск, а разработчиков. Их риск, их ответственность. Не твоя.

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

Ну вот лично я — один из людей, благодаря фидбэку которых из гнома не оторвали клавишу compose в вяленде.

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

А причём здесь данное утверждение, если вы назвали наглым враньём совсем другое, а именно:

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

Почему нужно, я объяснил, — ибо существуют композиторы без поддержки xdg-decoration (поскольку его поддержка опциональна), а значит, для них необходимо рисовать декорации на стороне клиента, если приложение хочет иметь декорации, — но вы это упорно игнорируете.

«Его всё равно нужно добавлять» — это враньё. Если бы в гноме была поддержка xdg-decoration, то всё бы просто работало без накостылевания поддержки CSD специально для гнома. На остальные композиторы, не поддерживающие xdg-decoration, всем абсолютно пофиг.

Не работает, поскольку в GNOME также одна из основных реализаций

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

Учитывая, что без xdg-decoration приложения абсолютно способны рисовать заголовки самостоятельно, оно не является необходимым по определению

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

Потому что вы так сказали?

Я уже объяснил почему. Но могу сказать и по-другому: имеют право.

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

Потому что разработчики гнома требуют от приложений, пишущихся под общую платформу «Linux/Wayland/XDG», добавлять специфичные для гнома костыли. И это не может нравиться никому, кроме фанатов гнома.

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

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

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

Я вам уже ответил, дурачок вы наш.

На тупняк вида «Почему разработчик вайргарда дал опенку правильный патч (дистрибутив), а бсдунам не дал?» — при том, что речь велась об исправлениях безопасности в одинаковых продуктах (конкретнее, для примера был взят openssl) — я даже не знаю, как отреагировать, кроме как громко посмеяться.

Но вы можете, например, ещё раз посравнивать число уязвимостей в Linux с 1999 года и в Windows 10 с 2015 года — не, ну а чо?

Ну или ответить наконец на вопрос, что же конкретно в приведённой вами же статье на cnews противоречит моим словам, как вы изволили заявить:

Я линк на сньюз привел. Там говорили не о тех вещах, о которых пишите Вы. Кто врет? Сньюз или Вы?

— но после нескольких требований привести конкретно, что там не так, предпочли слиться:

Нет зачем. Я старый, пожилой, больной человек. Глаза уже не видят. Думал Вы прочитаете и мне расскажите. А Вы в упор не хотите :( Придется так и помереть в незнании.

Так что же в той статье противоречит тому, что написал я, а?

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

при том, что речь велась об исправлениях безопасности в одинаковых продуктах (конкретнее, для примера был взят openssl) — я даже не знаю, как отреагировать, кроме как громко посмеяться.

Иванушка, я расплакался. Дурачком растешь.

Почему мои девелоперы пилят патчи для условного опенссл для каждой платформы отдельно? Они мне врут или ты? Или они криворукие а ты гений? В чем секрет?

Но вы можете, например, ещё раз посравнивать число уязвимостей в Linux с 1999 года и в Windows 10 с 2015 года — не, ну а чо?

Потерянный рут, ты ниасилил в логику почему вынь с 15года. Обьясню. Потому что вынь 10 релизнулась. Ты это не смог. Как и не смог в поиск скажем вынь7 на том же сайте.

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

Так что же в той статье противоречит тому, что написал я, а?

Музыка приглушалась. Занавес.

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

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

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

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

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

Ну или ответить наконец на вопрос, что же конкретно в приведённой вами же статье на cnews противоречит моим словам,

Ок. Я не злой. Сжалюсь. Тем, что указанные уязвимости существовали много много лет до того, как их локализовали заинтересанты. А пользовали кому надо их оч долго. Дошло надеюсь.

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

«Его всё равно нужно добавлять» — это враньё.

Нет. Потому что при условии что xdg-decoration — это опциональное расширение, поддержки которого может не быть в любом отдельно взятом композиторе, то приложению, которое хочет иметь заголовок (1), но не смогло согласовать отрисовку его на стороне сервера по опциональному расширению xdg-decoration, следует отрисовать его самостоятельно, ибо в противном случае у него под данными композиторами заголовка не будет вовсе, а это противоречит изначальному требованию приложения (1).

Замечу, что в вышеприведённом абзаце нет слова GNOME.

На остальные композиторы, не поддерживающие xdg-decoration, всем абсолютно пофиг

Импликация «мне абсолютно пофиг» → «всем абсолютно пофиг» неверна. Надо объяснять, почему?

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

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

Потому что разработчики гнома требуют от приложений, пишущихся под общую платформу «Linux/Wayland/XDG», добавлять специфичные для гнома костыли. И это не может нравиться никому, кроме фанатов гнома.

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

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

Мы-то не пропадем

Именно. Ну и в чём тогда проблема, которую раскатали на 14 страниц?

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

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

Какие «композиторы, не поддерживающие xdg-decoration»? Драма связана с гномом, а остальными пользуется от силы 1 % от пользователей Wayland на десктопе. Сделал бы гном поддержку xdg-decoration — не было бы никаких разговоров про костылинг CSD к приложениям, традиционно использующим SSD. Если у какого-то Enlightenment не работают SSD, то это уже его проблемы; если хотят, чтобы у них нормально отображались приложения, которым нужны SSD, то пусть добавляют поддержку соответствующего протокола (который опционален, потому что телефонам, embedded и пр. не нужны декорации вообще).

Опять же, ни одной уважительной причины не добавлять xdg-decoration в Mutter названо не было.

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

Ну и в чём тогда проблема, которую раскатали на 14 страниц?

Ну как же в чем? В длительных, особо жгучих отношениях двух противоборствующих сторон :)

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

Заголовки окон — это рудимент из 80-х годов

Чего это в них такого устаревшего, м?
Окно надо за что-то перетаскивать. Да, сейчас некоторые тулкиты и/или темы умеют инициировать перетаскивание за любую часть окна без активного контрола. Однако, приложение может зависнуть и тогда его перетащить будет не так удобно, надо будет super зажимать. Большинству окон нужны названия, чтобы их различать. Вроде этот аспект всё ещё вполне актуален... А! Или это сарказм такой?

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

Почему мои девелоперы пилят патчи для условного опенссл для каждой платформы отдельно? Они мне врут или ты? Или они криворукие а ты гений? В чем секрет?

Речь шла конкретно про openssl, дурачок вы наш. И я даже объяснял вам, почему:

Затем, что сравнивать нужно сравнимое. Вот я и взял openssl, который в обеих ОС используется один и тот же.

Более того, даже вы сами так запросили с самого начала:

Сравните пингви и бсдю. Одни и те же даже софтины

Вот я и сравнил одну и ту же «софтину»: openssl (и немножко wpa).

А когда оказалось, что в Debian патчи безопасности openssl применяли несколько быстрее, чем в вашей любимой FreeBSD, то вы попытались соскочить на якобы разное качество этих патчей:

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

Это о реалиях в контексте холивара. И если бсдя медленнее, но вернее фиксит, то в руки им флаг.

На что я вам резонно указал, что патчи в обеих ОС идут из upstream openssl¹. После чего вы и начали вопрошать про патчи реализации поддержки WireGuard — как будто они имеют хоть какое-нибудь отношение к обсуждаемым патчам безопасности в общих продуктах вроде openssl. Видимо, логическая связь между ними для вас заключается в общем слове «патч».

¹ Если взять, например, исправления CVE-2021-3711 и CVE-2021-3712 в Debian, то во-первых, можно посмотреть, откуда были взяты эти патчи — из upstream! — а во-вторых, в FreeBSD использованы ровно те же самые исправления: раз, два, три, четыре (за исключением пары тестов).

Так что всё ровно так, как я и говорил: в общих продуктах вроде openssl исправления что в Debian, что в FreeBSD попадают из одного источника: upstream.

Вот о чём с вами разговаривать, с таким-то вашим знанием предмета?

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

Ок. Я не злой. Сжалюсь. Тем, что указанные уязвимости существовали много много лет до того, как их локализовали заинтересанты. А пользовали кому надо их оч долго. Дошло надеюсь.

А теперь смотрим, что я написал:

Первая уязвимость имеет рейтинг 7,2, опубликована 20 июля, исправлена в Debian 18 Jul 2021 08:52:00 +0200.

Вторая имеет рейтинг «аж» 4,9, опубликована тоже 20 июля, исправлена в Debian 08 Jul 2021 15:03:45 +0200.

Это ни одним словом не противоречит написанному в статье.

Однако же, вы в ответ написали следующее:

В контексте диалога на синьюс указаны другие сроки. Кто врет?

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

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

Rootlexx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.