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

Он-то хотел статистику посмотреть, а выполнилось «Удалить все данные».

Во первых при таких типах действий обычно показывается диалог подтверждения. Во вторых зависание происходит обычно не в рандомные моменты, а например после нажатия на кнопку. В таком случае кнопка мыши будет уже отпущена. То есть вероятность проблемы крайне мала. Длительные действия с зажатой кнопкой мыши это либо рисование, либо таскание (но не drag&drop). У маководов есть ещё навигация по меню с зажатой кнопкой, но это проблема маководов и там легко получить ложное срабатывание при нестабильном физическом контакте кнопки мыши. При поспешной генерации сообщения отпускания кнопки мыши фатальных последствий произойти не должно.

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

Это уже гадания на кофейной гуще пошли, опять.

Длительные действия с зажатой кнопкой мыши это либо рисование, либо таскание (но не drag&drop).

Откройте для себя работу с меню через «нажатие → перемещение → отпускание» вместо «нажатие → отпускание → перемещение → нажатие → отпускание».

Откройте для себя работу с меню через «нажатие → перемещение → отпускание»

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

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

И при чём здесь маководы, если это работает и в Linux?

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

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

1. wl_pointer_send_leave
2. wl_pointer_send_enter
3. wl_pointer_send_motion

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

Да, детка, большой всратой эвристики богу всратой эвристики.

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

Ничоси, тема про Wayland с техническим обсуждением, а не традиционное метание какашками и смайликами клоуна.

KDE у меня на нем не работает, я не могу воспользоваться его преимуществами, если они вообще есть

УМВР. На протяжении уже нескольких лет.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/238

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

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

1. Кольцевой буфер «ресайзить» достаточно просто: последним сообщением перед переполнением присылаем ссылку на новый буфер. Таким образом кольцевые буферы образуют односвязный список. По мере их опустошения память освобождается. Каждый такой буфер имеет смысл делать размером в одну страницу памяти. Ну и длину списка стоит ограничить достаточно большим числом.

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

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

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