Переключение фокуса из контекстных меню в KDE Plasma 5

Если я правильно помню, это проблема вовсе не кед, а самих Х-ов. Проверь это поведение в другом DE. Думаю, там будет аналогичная проблема.

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

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

:(

ЕМНИП это «фича» иксов. И её, к слову, никак не отключить. Это из той же серии что и невозможность использовать мультимедиа кнопки при включеном скринсейвере. Ибо для иксов и скринсейвер и контекстное меню одно и тоже. И это «одно и тоже» набигает и грабит корованы перехватывает абсолютно весь инпут, и пока его не закроешь, другие приложения никакой инпут (в твоем случае это клик мышкой) не получат.

Это с одной стороны. А с другой — можно невозбранно скролить мышью неактивное окно. До того уже привык к этой мелочи, что редкие сеансы работы под оффтопиком (где это невозможно) вызывают дикое раздражение :)

Переключение фокуса из контекстных меню в KDE Plasma 5 (комментарий)

Именно поэтому тач на линуксе УГ. Тут на лоре выдвигалось как то такое предположение, что онтопик непопулярен на пк именно изза иксов. Ибо везде, где иксы выкидывались или за ненадобностью или изза NIH велосипедов, пингвин довил конкурентов.

Это с одной стороны. А с другой — можно невозбранно скролить мышью неактивное окно

При вызвоном контекстном меню не работает ЕМНИП. Меню после первого срабатывания пропадает. Ща доберусь до компа — проверь.

Да, попапы в иксах ядерные, перехватывают любой фокус...

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

Проверил. Меню чхать хотело на кручение колесом, не отдаёт фокус, и всё.

невозможность использовать мультимедиа кнопки при включеном скринсейвере

В кедах иксовых работает.

В кедах иксовых работает.

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

X11 on a protocol level doesn’t know anything of screen lockers. This means there is no privileged process which acts as the one and only screen locker. No, a screen locker is just an X11 client like any other (remote or local) X11 client connected to the same X server. This means the screen locker can only use the core functionality available to “emulate” screen locking. Also the X server doesn’t know that the screen is locked as it doesn’t understand the concept. If the screen locker can only use core functionality to emulate screen locking then any other client can do the same and prevent the screen locker from locking the screen, can’t it? And yes that is the case: opening a context menu on any window prevents the screen locker from activating.
...
And interestingly I chose to use the technology which will solve all those problems: Wayland. While we don’t use Wayland as the windowing system we use a custom domain-specific Wayland-based protocol for the communication between the parts our screen locker architecture. This uses the new libraries developed for later usage in kwin_wayland.

https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cann...

Интересно! Читал блог Мартина, но как-то проглядел этот момент.

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

Ой, а кто у тебя на аватарке?

https://www.youtube.com/watch?v=bl8kpplD2l8