Red Hat угощает Wayland-ом разработчиков Firefox

Те, кто громче всех орет какие Х говно и как wayland лучше.

Те, кто громче всех орет какие Х говно и как wayland лучше.

Ну вот у них и спрашивай :D

Вейланд пишет кучка гиков, повернутых на KISS и инновациях.

и инновациях

Это которые всё ещё explicit sync запилить не могут?

Это которые всё ещё explicit sync запилить не могут?

Понятия не имею что это.

Вейланд пишет кучка гиков,

Вопрос на засыпку, зачем тогда ЭТО проталкивают как единственно возможный способ, депрекейтя предыдущий? Аргумент «никто не знает как работает Х» - очень херовый. На него есть исходники, а объем кода меньше, чем мой рабочий проект. Пофиксить в нём некоторые вещи было проще (пусть даже с частичным сломом протокола, например чтобы починить глобалки при сворованном фокусе)

Кто и куда проталкивает-то, я никак понять не могу? Есть мейнтейнеры de, которые говорят что даже так лучше чем иксы. Есть мейнтейнеры дистров, которые в отличии от мнения LOR, просто идут в ту же сторону, куда идет апстрим. Кто из этих людей кого куда проталкивает?

Кто и куда проталкивает-то, я никак понять не могу?

Простите, вы последние 3 года были в контейнере на дне моря? Red Hat (за чей счёт всё это и разрабатывается) объявила что иксы не нужны и периодически с разной степенью успешности пытается их вырубить по дефолту. Остальные дистры подражают. Разрабы иксов после этого поуходили, вместо них поставили тех же клоунов в юбках, что разрабатывают wayland.

Есть мейнтейнеры de, которые говорят что даже так лучше чем иксы

Можно пример таких заявлений, пожалуйста? Пока что я вижу критические сложности имплементации например в кедах.

Не вижу смысла решения статистически незначимых абстрактных проблем в вакууме

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

А вот падения программ от движения мышью – это реальная серьёзная проблема приводящая к потере данных.

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

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

Так флаг же не загорится, никто не нажмет после этого кнопку ОК.

Что? Можно расшифровать?

Решать проблемы исключительно по мере поступления — значит превратить проект со временем в сборище костылей

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

Не хочу показаться занудой, но…

Твой X-сервер ещё не упал по OOM?

Не припомню такого за 15 лет использования.

Yet another anecdotal evidence.

Код выше по треду. Запусти и насладись гениальностью дедов, написавших идеальные иксы.

Только все открытые файлы сохранить не забудь.

Можно пример таких заявлений, пожалуйста?

https://blog.martin-graesslin.com/blog/2018/01/kwinx11-is-feature-frozen/

Человек нажимая на checkbox, не увидит что он был отмечен в состояние ON, а значит и кнопку не нажмет, пока не убедится в том что checkbox действительно ON а не OFF.

Т.е. дело только в тестах? Звучит как какая-то не очень отмазка почему они переходят. ИМХО они это делают только потому что боятся не успеть впрыгнуть в паровоз, когда RH окончательно отдепрекейтит иксы.

Человек нажимая на checkbox, не увидит что он был отмечен в состояние ON, а значит и кнопку не нажмет, пока не убедится в том что checkbox действительно ON а не OFF.

Извините, но вы сильно ошибаетесь. Учитывая, что в 99,9…% случаев элементы интерфейса на нажатия таки реагируют, практически никто кроме совсем уж параноиков не останавливается на долю секунды после каждого действия, чтобы проанализировать обратную связь. Если это действие выполняется регулярно, то будет быстрый щелчок по флажку и расположенной рядом кнопке, исходя из ожидания соответствия поведения предыдущему опыту. См. многочисленные исследования на эту тему, подкреплённые примерами из внедрения UAC в Windows.

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

Тогда пользователь еще может кликнуть не туда, а потом нажать кнопку ОК, раньше же он попадал по чекбоксу всегда.

Так что предлагаю в GTK5, если будет появляться окно с чекбоксами, блокировать весь вывод, и в CLI интерфейсе заставлять пользователя на каждый чекбокс писать причину почему он хочет сделать его ON или OFF, а изначально у него будет третье неустановленное состояние, так победим.

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

Там у него весь блог в записях вида «Вот такие у нас костыли в X11, а в Wayland всё значительно проще».

Тогда пользователь еще может кликнуть не туда, а потом нажать кнопку ОК, раньше же он попадал по чекбоксу всегда.

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

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

Клоунаду с «предложением» оставлю без комментариев.

…например:

• https://blog.martin-graesslin.com/blog/2015/09/comparing-dpms-on-x11-and-wayland/

• https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/

• …

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

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

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

Но может просто вернуться в реальность? Wayland разрабатывается уже 15 лет, KDE у меня на нем не работает, я не могу воспользоваться его преимуществами, если они вообще есть. Люди с мышкой не за 100 рублей не могут даже использовать Firefox, я уверен, это приложение является одним из самых популярных на линукс-десктпое.

Мне как пользователю даже непонятно на что он вообще жалуется.

Прямо сейчас я могу использовать для работы ТОЛЬКО X11.

“Talk is cheap. Show me the работающее приложение”

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

А в Киеве дядька. При чём тут фокус? Мы говорим о событиях мыши, а не клавиатуры.

А задача графической системы — правильно обрабатывать события. Вся система построена на взаимных гарантиях компонентов. Предложить на эти гарантии забивать — это путь в никуда. Вон, товарищ выше в своём примере тоже поменял местами события перемещения мыши и нажатия на кнопку. Отличный план!

При чём тут фокус? Мы говорим о событиях мыши, а не клавиатуры.

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

И чувак, который на планшете рисует, получает вместо линии точку.

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

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

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

Это можно заметить уже после того как нажал на кнопку.

У тебя синтетический пример.

Докопались к примеру… Не нравится — приведите другой. Суть от этого не меняется: просто так дропать события нельзя.

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

Такому пользователю можно только посоветовать протереть шары мозг

просто так дропать события нельзя

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

Red Hat (за чей счёт всё это и разрабатывается) объявила что иксы не нужны и периодически с разной степенью успешности пытается их вырубить по дефолту.

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

Можно пример таких заявлений, пожалуйста?

Не вопрос: https://pointieststick.com/2023/09/17/so-lets-talk-about-this-wayland-thing/

Автор — один из наиболее активных разработчиков KDE.

Why does Wayland exist? In a nutshell, because X11–the thing it’s replacing–is dead.

X11 has been in maintenance mode for years, and recently has gotten no real development at all other than changes to the XWayland compatibility system that allows X11 apps to use a Wayland compositor. Having something as central as the window server being unmaintained is a major issue, as it means no bug fixes, no security patches, and no new features to let it keep up with a changing world.

Why did X die? The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible. Everyone strongly preferred to standardize on a single X server and migrated in unison from one to another when a better fork became available, because it was convenient. And it was convenient because because it centralized limited development resources, and when a feature was added to the X server, everyone gained access to it automatically.

But there was a drawback: because everyone was using Xorg, any feature added to support any use case could break everything else that everyone else used, and this happened frequently. Bug fixes frequently regressed obscure functionality that others were using.

In essence, Xorg became too large, too complicated, and too fragile to touch without risking breaking the entire Linux ecosystem. It’s stable today because it’s been essentially frozen for years. But that stability has come hand-in-hand with stagnation. As we all know in the tech world, projects that can’t adapt die. Projects that depend on them then die as well.

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

Прям аксиома эскобара

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

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

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

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

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

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

Решение конкретно таких проблем уже есть – динамический ринг буфер, как в же тех иксах. Уже даже есть патч. Осталось кому-то сделать последний шаг и засунуть его в libwayland.

Мартин Странски из Red Hat написал Wayland-Proxy как C++-версию предыдущей экспериментальной концепции, написанной на Rust

Растишка — йезыг эспериментальных концепций. А что эту «концепцию переписали на плюсы — это чисто анекдот „Концепция изменилась...“

Убивать рандомные приложения от неловкого движения мышью – вот настоящие специалисты! (facepalm)

Решение этой проблемы лежит совсем не в плоскости «А давайте угадаем, какие события приложению не нужны!».

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

Большинство серьёзных GUI систем таких как MS Windows делают отбрасывание событий при переполнении.

Если не отбрасывать сообщения, то переполнение – это вопрос времени

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

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

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

Если приложение в принципе не успевает обрабатывать события — это проблемы приложения, и ему уже ничем не помочь.

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

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

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

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

Продолжайте клоунаду с оправданием прибивания рандомных приложений

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

Программа может быть под отладкой.

И представьте себе, при этом возникают самые разные проблемы, от таймаутов поллинга до разрыва сетевых соединений удалённым сервером!

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

Это стандартное проверенное индустрией решение применяемое на ~95% десктопов. Не я его придумал. Это уникальные снежинки в Wayland придумывают что-то альтернативно-одарённое идущее в разрез с требованиями бизнеса.

до разрыва сетевых соединений удалённым сервером!

Тут нет никакого удалённого сервера. UNIX сокет можно ожидать бесконечно долго. Прекращайте шланговать.

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

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

Теоретически, можно было бы предложить протокол, позволяющий клиенту уведомить сервер об этих критериях. Например, если программе не нужны события перемещения мыши с частотой больше 120 Гц, то она могла бы попросить сервер ограничить event rate для данного типа сообщений. Аналогично, можно было бы разрешить серверу сквошить определённые сообщения. Главное в этом подходе то, что инициатива исходит от клиента как единственного субъекта, обладающего информацией о последствиях данных решений и потому способного подобрать критерии, не снижающие надёжность.

подобрать критерии, не снижающие надёжность.

Всё это звучит смешно когда люди оправдывающие рандомные падения приложений что-то говорят про надёжность. ЛЮБОЕ решение с пропуском сообщений будет априори лучше рандомных падений. Даже тупо пропуск всех сообщений ввода после зависания. Да, после зависяния програма будет думать что кнопка мыши всё ещё нажата, но это легко обходится нажатием и отпусканием в свободном месте окна. Главное что программа не упадёт и не потеряются важные данные/результаты вычислений. ОС должна спасать жизнь приложений ЛЮБОЙ ЦЕНОЙ, иначе это говноось, не заслуживающая доверия бизнеса.

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

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

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

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

КАКОЙ УЖАС! Сообщения мыши пришли не в том порядке! Срочно прибить приложение!!!

Самому не смешно? Это же полнейший пустяк.

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

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

Элементарно: вызов совершенно не того пункта меню, на который рассчитывал пользователь.

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

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

Если вам непонятны такие элементарные вещи, то разговаривать просто не о чем.

Это обсуждение напомнило, как много лет назад пришлось писать костыль с виртуальной мышкой через uinput для обхода похожей проблемы в Unity при работе с сенсорными экранами, когда активация происходила по предыдущим координатам события ввода:

        if (got_x && got_y) {
            emit_mouse_move(x, y);

            if (got_touch) {
                /*
                 * Unity3D somehow manages to ignore valid input event
                 * coordinates and uses the previous ones instead. Let's
                 * jerk the 'mouse' a bit to get around it.
                 */
                emit_mouse_move(x - 1, y - 1);
                emit_mouse_move(x, y);

                emit_mouse_button(1);
                got_touch = 0;
            }
        }

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