А вы помните бесячий баг иксов, который всегда раздражал?

У меня проблемы с фокусом появились в версии 18.04, до этого (в 12.04) никаких проблем не было. И, как я понял, связано это с появлением Gtk3 (вместо Gtk2).

Конкретно этот сабжевый баг – родовая травма иксов, оно было там даже наверное всегда. Аффектятся как приложения на GTK+2,3,4 так и на Qt 4,5,6.

Эээ… Во первых это не баг.

А что это, фича? Почему на Wayland и macOS нет этой идиотии и не нужны никакие костыли-задержки?

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

Как в Wayland поменять настройки устройств ввода (клавиатуры, мышки, тачпада)?

man libinput

И эти люди хотят feature-parity с иксами, да.

Это на самом деле круто, мне тоже этот баг мешал. Но сказать по правде, это первая фича в плане UX (а не внутренней кухни) из-за которой мне захотелось перейти на вейланд.

Они не смогли это реализовать.

Или мамку.

Век живи — век учись. Точно ведь, проверил — есть такой баг. 25 лет с линуксами не знал о его существовании, никогда не требовалось сшотать меню.

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

Стоп. С каких пор модульность сервера стала проблемой протокола? Это детали имплементации конкретных серверов. Если какой-то сервер сделает плагины для всего этого — будет всё юниксвейно. Можно ещё сделать кроссДЕ-шный стандарт для них, на который всем будет пофиг. Но вообще монолитный софт проще писать, поэтому чаще так.

Встраивать IPC в wayland только потому, что в иксах от этих самых иксов в 2к22 году используют почти исключительно IPC — противоположность юниксвею.

С каких пор модульность сервера стала проблемой протокола?

С таких, что в одном голом протоколе нет смысла. Для функционирующего десктопа необходим комплекс протоколов/API/интерфейсов плагинов. X11 предоставлял этот комплекс включая плагины серверных видеодрайверов со стабильным API/ABI.

Ну так это проблема не wayland’а, а недостатка людей, которые эти апи будут дизайнить.

Это проблема именно Wayland потому что нет никакого смысла делать голый протокол в вакууме без сопустствующей инфраструктуры.

Почему на Wayland и macOS нет этой идиотии

На Wayland — потому что он проектировался с оглядкой на эту проблему в том числе. Если бы там оставалась та же проблема, то это был бы великий фейл. Кстати, проблема с DPI, похоже, будет решаться костылями, хотя могли бы и придумать решение поадекватнее, чем «ой, всё!»

На macOS — потому что жёсткий контроль. Они просто имеют возможность сломать пользовательские приложения, и никто из-за этого вой не поднимет. Компании важны деньги, а на всё остальное по большому счёту плевать, пока денежный поток течёт.

X11 предоставлял этот комплекс включая плагины серверных видеодрайверов со стабильным API/ABI.

Ты смешиваешь X.Org, реализацию сервера с поддержкой X11 и протокол X11. В самом протоколе, очевидно, ни про какие плагины речи нет. Плагины для X.Org не подойдут к другой реализации икс-сервера.

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

Ты смешиваешь X.Org, реализацию сервера с поддержкой X11 и протокол X11.

По факту нет никакого отдельного протокола X11. Протокол изначально разрабатывался совместно с реализацией в рамках проекта Athena. Можно и сейчас скачать эти исходники реализации, включая предыдущую версию X10. Альтернативные реализации протокола X11 существуют, но они существенно отстают по полноте реализации и функциональности и практически не используются. Так что я убеждён что протокол X11 и код реализации сервера восходящий к проекту Athena – это единое целое и глупо их делить.

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

Навскидку: запустить x11vnc и снять скриншот через vnc

vncsnapshot - A utility that takes JPEG snapshots from VNC servers

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

Желающие могут проверить, запустив sleep 15; pkill --signal STOP <имя приложения>, и пока sleep выполняется, переключиться в соответствующее приложение и открыть контекстное меню.

В Wayland-сеансе же что в GNOME, что в KDE остаются доступны глобальные сочетания клавиш, вроде нажатия Super в первом (переход в режим обзора) и Ctrl+Esc во втором (открытие менеджера процессов).

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

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

Конкретно этот сабжевый баг – родовая травма иксов, оно было там даже наверное всегда.

Не было. Например, в Geany/Gtk2 при переключении на другую вкладку фокус переходил на редактор (как и должно быть), а в Geany/Gtk3 - фокус остаётся на вкладке (что пиzd$ts как бесит). Код Geany при этом особо не менялся - чуваки только заменили вызовы Gtk2 на Gtk3.

https://imgur.com/a/JRt4Eo6
Шо?

Да, меню пропадает при смене фокуса. Нет, оно пропадает после скриншота и на скрин попадает.

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

Окей. Где тогда описания API/ABI плагинов X11?

И ещё, в каком месте API/ABI были стабильными?

Я был уверен, что это фича.

Не было. Например, в Geany/Gtk2 при переключении на другую вкладку фокус переходил на редактор (как и должно быть), а в Geany/Gtk3 - фокус остаётся на вкладке (что пиzd$ts как бесит). Код Geany при этом особо не менялся - чуваки только заменили вызовы Gtk2 на Gtk3.

Вот я не поленился, взял дистрибутив RHEL 4, который вышел в 2005 году и был актуален до 2009 года, с ванильным и древним GNOME 2 без всяких GTK+3 и проверил присутствие этого бага там:

https://baat.exlmoto.ru/~exl_lab/movies/X11_Screens_PrintScreen.webm

Жмём Print Screen при любом открытом контекстном меню и ничего не работает. Эта хрень с фокусами как уже сказали выше именно в иксах.

Вы о разных вещах спорите.

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

А если переключатель на другом сочетании клавиш, то проблемы нет?

// Удивился мотофану, я там был модератором или каким-то ведущим раздела кучу лет назад, правда ник уже не вспомнить. А ты там администратор, оказывается. Мир тесен, но я не думал что оно все ещё живое.

А если переключатель на другом сочетании клавиш, то проблемы нет?

Вроде как нет, но нужно будет проверить. Просто лень менять комбинации, жонглировать туда-сюда сеансами. Будет время – посмотрю.

но я не думал что оно все ещё живое.

Да. Хочу сохранить этот форум как можно дольше во времени. Сделать что-то типа архива. Если у тебя сохранились какие-нибудь файлы тех времён в каких-нибудь BackUp’ах – будет здорово если ты мне их отправишь.

А если переключатель на другом сочетании клавиш, то проблемы нет?

Проверил. При использовании виндовой комбинации Alt+Shift в X.Org-сеансе подобной проблемы в этом текстовом поле не наблюдается.

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

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

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

Баг заключается в чём? В иксах не предусмотрено, что такие вещи надо решать и не написан соответствующий код - не баг, отсутствие функционала и мнение, что не им этим заниматься. В кутях не предусмотрено и поэтому не написан соответствующий код - не баг, отсутствие функционала. А в гтк написан, но работает криво - вот где баг! Иксы не при чём и вейланд не при чём, тут даже оконный менеджер скорее иноват, а не они. Это написано в самих библиотеках туллкитов и только в них работает или не работает. Устраивать на этом срач что лучше, иксы или вейланд - глупо. И очень удивляет, прямо, детское хейтерство и слепая, циплячья неразборчивость ТСа. Казалось бы, уж ему должно быть понятно откуда вилы?

но активное меню перед этим закрывается.

Фича же.

В Window Maker, в gtk 1 и кажется gtk2 - detachable menu для такого.

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

Смешались в кучу кони, люди…

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

(И нет, включение XF86Ungrab не является решением, поскольку это дыра в безопасности.)

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

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

В иксах на Spectacle точно такие же баги.

Наверное по той же причине, почему в Linux нельзя повесить переключение раскладки на Ctrl+Shift без того, чтобы сломать все хоткеи

Вы имеете в виду в консоли? А то в KDE УМВР

Хз о чем ты. Всегда пускал скрота или KScreenshot/Spectacle с дилеем в 5 секунд и никогда не имел никаких проблем: Alt+F2 -> spectacle -c -d 5000 -> за пять сек открываешь все меню и все что нужно -> когда скриншот сделался диалоговое окно с кепчуром открывается… Profit!

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

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

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

Пытаться пересадить всех на wayland, говоря об безальтернативности - тупиковый подход.

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

А сугробо по теме - думал ты сам троллишь сначала. Первый раз из темы узнал, что это «баг». Поставить на 5 сек таймер скрина, вообще прям проблема?! Прям, как сказали: «киллер фича wayland» :)

И тема всерьёз обсуждается на несколько страниц. Вы серьёзно?

Upd. С мобильного пишу, могут быть ошибки автозамены.

Иксы лучше вяленого. Как обладатель стильных модных молодёжных HiDPI мониторов говорю. На них на современном вяленом работать невозможно. Под иксами хорошо. Тиринга не давно не видел. 2 системы, одна с rx580, вторая с rtx3060 на блобе.

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

Как обладатель стильных модных молодёжных HiDPI мониторов говорю. На них на современном вяленом работать невозможно

Хм, а можно раскрыть тему? А то работаю в GNOME/Wayland на экране с 243 ppi и никаких проблем не испытываю.

Ноутбук 15.6" 1080p и к нему монитор 27" 2160p. Комфортный масштаб 1.5. Когда GNOME использовал, в нём поддержки не было. Вернее была, но экспериментальная, и то тут то там вылазили косяки и мыло. В KDE проблем нет, но мыло. Под иксами в KDE картинка идеальная и на 1, и на 1.5

Вероятно проблемы с масштабированием. Я тоже не сталкивался, но вайлэнд умеет только в целочисленное масштабирование. Как мне объяснили здесь - x1,5 работает как x3/x2

Ага пока писал, вы ответили. Мыло, да?

Да. И именно из-за 1.5 = 1*3/2. Чем они думали, когда стандарт без учёта вариативности ppi утверждали - я не знаю

Так а всё в таком качестве или только шрифты? Прочитал правки, понял, значит всё в таком качестве. Ну, это ппц.

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

Ноутбук 15.6" 1080p и к нему монитор 27" 2160p. Комфортный масштаб 1.5.

А, ну так сразу и писали бы, что вы о дробном масштабировании. Эта проблема есть только на недо-HiDPI экранах, чего явно недостаточно, чтобы заявлять, что «на HiDPI в Wayland работать невозможно».

(Вроде в Mac OS тоже используется подход с отрисовкой в большем разрешении и последующим уменьшением — там тоже мыло?)

Под иксами в KDE картинка идеальная и на 1, и на 1.5

GTK-приложения всё равно масштабироваться не будут и останутся на 1×, т.е. единообразия не будет. Плюс то тут, то там будут вылазить ошибки округления (разная наблюдаемая толщина одинаковых линий).

Я бы в таком случае, скорее всего, оставил бы интерфейс единичного размера и увеличил бы только шрифты.

Эта проблема есть только на Wayland.

FTFY. А вот легаси в виде X.Org, почему-то, корректно обрабатывает эту ситуацию.

Вроде в Mac OS тоже

мыло. На чём угодно с ощутимо отличным ppi от их дисплеев. Смузихлёбы на их опыт, похоже, и опирались. Забыв, что линукс не только на макбуках запускаться должен.

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

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

Я бы в таком случае

Как-нибудь выкрутился, лишь бы не признавать кривость вяленого (как протокола, а не конкретной его реализации). Я под иксами в kde сказал «скейлить в 150%», и всё ок.

ЗЫ А мониторы которым необходим 2,5 или 2,75 - они пере-hidpi и тоже плохие, ибо вяленый в них не умеет?