30 лет исполнилось X11

то программист 10 раз подумает, надо ли ему столько геморроя.

Вот именно, wayland=геморрой. А зачем кому-то себе добровольно геморрой устраивать?

надо ли ему столько геморроя

Ну тебе точно геморрой не грозит, питушок.

Может OpenBSD?

Очень может быть. Если так дальше пойдёт, то переход на *BSD я рассматриваю весьма серьёзно.

Возьмите один DE

и выкиньте его на помойку. Потом возьмите ещё один и выкиньте вслед за первым. И так пока не кончатся эти проклятые унылые DE с их иконками и тормозами.

NB: лично я продолжаю работать на fvwm2, могу ещё IceWM терпеть, и даже некоторые другие WM. Но никогда — ни одно из тех поделий, которые имеют наглость называться Desktop Environment. Вообще не понимаю, как люди с ними работают.

сам запускает процесс обновления дистра, а потом ноет

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

стандарт де-факто

О! Да! Ключевое слово произнесено!

Если просто техническая стандартизация — ну всякие там ISO, ANSI и W3C — это просто особый (и особо опасный) вид международного терроризма, ну мало ли бывает террористов, их просто надо перестрелять, и всё будет хорошо, ... ээ... то как только где-то по какому бы то ни было поводу звучит словосочетание «стандарт де-факто», это есть бесспорный сигнал о том, что стрелять нужно прямо сейчас.

кому в ногу?
AT&T || BSD?
Два стандарта, как зародились, так и тянутся своими когтистыми костяшками зомбаков.. :-)

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

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

У них чёткая концепция: программа может распоряжаться только внутри своего окна и ни на другие, ни в десктоп лезть на должна.

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

и Охрененно Гениальные Разработчики Опупенно Прогрессивного Вейлянда таки начали осознавать это, кажись, годика 2 назад (как в анекдоте: а на третий день Соколиный Глаз заметил, что одной стены нет!), а вот вейляндофаны до сих пор пребывают в блаженном невежестве

речь о контекстных меню; в винде и линуксе (наверно и в макоси — я не пробовал):

1. контекстные меню *перекрывают* в т.ч. *чужие* окна

2. направление развертывания контекстного меню (вверх или вниз от пойнтера мыши, вправо или влево от пойнтера мыши) определяется исходя в т.ч. из доступного места до края *экрана*, а не до края *окна*

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

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

а кто-то вырежет функциональность, не получив взамен никакой безопасности. // FIXED

1. контекстные меню *перекрывают* в т.ч. *чужие* окна

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

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

Так вот, контекстное меню - это тоже окно. Оно накрывает родительское и может выходить за его пределы, перекрывая другие.

2. направление развертывания контекстного меню (вверх или вниз от пойнтера мыши, вправо или влево от пойнтера мыши) определяется исходя в т.ч. из доступного места до края *экрана*, а не до края *окна*

Я так понимаю, главная проблема не в этом. Дисплейсервер вполне может подвинуть попап, если тот куда-то вылез. Дело в том, что многие программы написаны из предположения, что приложению доступна информация об абсолютных координатам окна и они пытаются задавать координаты попапа в относительно экрана. Если с тулкитами ещё как-то можно жить, заставить при обновлении какой-нибудь QT не пользоваться абсолютным позиционированием, то в случае wine всё вообще плохо. Ну в общем пока есть xwayland вайн может переждать пока устаканится.

2. направление развертывания контекстного меню (вверх или вниз от пойнтера мыши, вправо или влево от пойнтера мыши) определяется исходя в т.ч. из доступного места до края *экрана*, а не до края *окна*

Я так понимаю, главная проблема не в этом. Дисплейсервер вполне может подвинуть попап, если тот куда-то вылез.

ты неправильно понимаешь — главная проблема именно в этом, и дисплей-сервер не может подвинуть попап туда, где ему быть лучше всего (хотя, конечно, может подвинуть тупо и произвольно — вейляндофану это надо объяснять; вейляндофан не догадается об этом сам, услышав «misplaced menus» 30 лет исполнилось X11 (комментарий))

для оптимального размещения попапа дисплей-серверу (или оконному менеджеру — что там у них?) надо знать куда его двигать, а для этого, в общем случае, нужно знать что попапу в «своем» окне можно перекрывать, что нежелательно, а что вообще нельзя — а этой инфой владеет только программа

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

Так вот, контекстное меню - это тоже окно. Оно накрывает родительское и может выходить за его пределы, перекрывая другие.

Так вот, контекстное меню - это тоже окно.

да пусть хоть Чаша Святого Вейляндотворца, мне пофиг

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

это по-прежнему нарушает ту четкую концепцию, которую ты высказал:

У них чёткая концепция: программа может распоряжаться только внутри своего окна и ни на другие, ни в десктоп лезть на должна.

именно, программа таки должна, даже в варианте попап=новое_окно лезть на десктоп, причем не только на чтение (а сколько места до края экрана?), но и на запись (приказываю размещать попап *именно* здесь)

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

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

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

спасибо, К.О., я в курсе об этом 25 лет или около того

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

при этом окно программы выглядит как трапеция (перспективные искажения); кто и как должен решать, где и *как* показать меню?

btw#1: обычные (неконтекстные) меню тоже могут выходить за край окна

btw#2: я считаю эти проблемы разрешимыми, но решаться они должны не идиотами, не в стиле «а нам пофиг, на смартфоне все равно приложение равно экрану», и не в стиле red hat «для гнома сделаем костыли через dbus, а на остальных нам насрать»

правильный подход — это разработать что-то типа css для этого, вплоть до полного отбора прав у программы распоряжаться менюхами

У них чёткая концепция: программа может распоряжаться только внутри своего окна и ни на другие, ни в десктоп лезть на должна.

Допустим, я хочу написать хитрый менеджер паролей, который будет удалять пароль из буфера обмена как только в любом окне была выполнена операция вставки из буфера обмена. Как это сделать на Wayland?

У них чёткая концепция: программа может распоряжаться только внутри своего окна и ни на другие, ни в десктоп лезть на должна.

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

AT&T || BSD?
Два стандарта

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

кому в ногу?

В голову. Каждому члену любого стандартизационного комитета. Персонально. Сейчас вот, например, после демарша EFF в W3C приличных людей не осталось, пора устраивать геноцид. Про тех, кто генерит новые стандарты C и C++ я вообще молчу, этих надо было пристрелить маленькими в кроватках.

ты неправильно понимаешь — главная проблема именно в этом, и дисплей-сервер не может подвинуть попап туда, где ему быть лучше всего (хотя, конечно, может подвинуть тупо и произвольно — вейляндофану это надо объяснять; вейляндофан не догадается об этом сам, услышав «misplaced menus»

Да ладно.

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

Пусть клиент не знает реального положения своих сурфейсов (даже относительно родительского), но знает их размер (иначе как рисовать?). Пусть при создании любого сурфейса можно указать желаемый размер, а WM может дать либо такой же, либо уменьшенный, чтоб помещался в экран. Пусть при создании дочернего сурфейса можно указать положение, относительно родительского, и пусть WM обещает уважать эту просьбу за исключением случая, когда вывод сурфейса в запрошенном месте приведёт к выходу за пределы экрана. Задача состоит в обеспечении в тулките нормально работающими попапами. Решение. Вопрос с прокруткой тривиален, у вас есть попап, известен его размер, если не влазит - добавляем прокрутку. С положением сложнее, но тоже в принципе решаемо. Во-первых попапы делятся на 2 класса, те, которые слабо привязаны к месту (например, контекстное меню должно только примерно под мышкой, но может быть и смещено) и те, которые жёстко привязаны к чему-то (например, выпадающая часть комбобокса, она должна рисоваться впритык к контролу снизу или сверху). С контекстным меню всё просто: тупо создаётся дочерний сурфейс в точке клика мышкой, в идеале на эту точку придётся левый верхний угол меню, если же оно выходит за границы экрана его просто подвинут. Попап комбобокса (или подобный же) делается просто внутри окна. Если под комбобоксом недостаточно места просто открываем его вверх. Дочерний сурфейс не создаём, сидим внутри окна. Ну и самый сложный вариант: что если попап должен быть привязан к контролу, но при этом окно настолько мало, что ни вниз, ни вверх его нормально не открыть? Довольно специфическая задача, но возможная, особенно если пользователь взял да сам уменьшил размер окна до тонкой полоски. В таких нестандартных ситуациях никто не осудит, если попап будет создан как дочерний сурфейс, он возможно перекроет родительский контрол, а чтоб его можно было закрыть тут же внутри него тулкит нарисует кнопку закрытия. Немного непривычно, но не более непривычно чем, скажем, докающиеся панели в своё время были.

Допустим, я хочу написать хитрый менеджер паролей, который будет удалять пароль из буфера обмена как только в любом окне была выполнена операция вставки из буфера обмена. Как это сделать на Wayland?

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

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

В-третьих, немного не по теме, но вообще странная у вас идея безопасного менеджера паролей. Если буфер обмена в системе сделан так, что им управляет только пользователь (только через ctrl-v вставляется, программа не может ни инициировать вставку ни даже посмотреть что в буфере), тогда решение более-менее безопасное, но непонятно нафига вообще чистить буфер с такой точностью, достаточно через 5 минут, например, всё равно без действия пользователя никто из буфера не прочитает. Если же буфер доступен программам по их инициативе, то сидящий в фоне троян украдёт пароль ещё до того, как пользователь его вставит. Ваша программа почистит буфер, пользователь увидит, что пароль почему-то не скопировался, так что ваш менеджер сначала будут считать глючным, а потом ещё и виноватым в утечке паролей.

С контекстным меню всё просто: тупо создаётся дочерний сурфейс в точке клика мышкой, в идеале на эту точку придётся левый верхний угол меню, если же оно выходит за границы экрана его просто подвинут

чувак, я начинаю подозревать, что компьютерный gui ты увидел ну никак не больше месяца назад (смартфоны/планшеты не засчитываются, если что) — поэтому, собственно, вейлянд и кажется тебе нормальным

если ты бы видел gui хоть сколько-то продолжительное время, ты бы знал, что контекстное меню в основном не двигают, а меняют направление его развертывания; сделай сам эксперимент и посмотри (но в дополнение к этому его и двигать тоже могут, да)

повторю себя:

направление развертывания контекстного меню (вверх или вниз от пойнтера мыши, вправо или влево от пойнтера мыши)

в твоем алгоритме где и когда определяется это направление? если чё — это требует попросить создать 4 окна, а затем уничтожить 3 из них (ну или получить метрику 4 окон, а не одного)

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

Спасибо. Я себе прогресс как-то не так представлял.

Таки прогресс. Одназадачная мобила с окном на весь экран - это сейчас основной интерфейс, а для новых поколений так и вовсе родной и единственно верный (им так кажется). Вот и подстраиваются гуиписатели под этих утят. Вы их не понимаете, они вас, взять хоть диалог с этим хрюнделем. Ждем голографический интерфейс у мобил, может тогда многооконность снова войдет в моду.

А зачем и без того успешному Андроиду X.org?

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

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

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

Однозадачная мобила с окном на весь экран - это сейчас основной интерфейс, а для новых поколений так и вовсе родной и единственно верный

Кстати говоря (если немного отвлечься от графических серверов) для множества применений это совсем неглупая концепция. Только в андроиде она реализована на редкость халтурно и затратно.

Древняя PalmOS 5, построенная по такой концепции, летала без каких либо лагов на куда более скромном железе, чем современные печки-лопаты. А благодаря тому, что каждое из стандартных приложений умело в нужный момент сохранять и восстанавливать свою конфигурацию, для пользователя однозадачность была практически незаметна. При этом тем приложениям, которым действительно нужна фоновая работа (например, плеерам), такая возможность предоставлялась, полноценная многозадачность для этого совсем не нужна.

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

если ты бы видел gui хоть сколько-то продолжительное время, ты бы знал, что контекстное меню в основном не двигают, а меняют направление его развертывания; сделай сам эксперимент и посмотри (но в дополнение к этому его и двигать тоже могут, да)

Разговор был о вменяемом поведении, а не о «чтоб было как раньше и никто даже не догадался, что у нас тут больше не xorg». Насколько принципиально, что контекстное меню, если справа недостаточно места, должно открыться влево, а не оказаться сдвинутым? Будет ли эта непривычность более раздражающей чем, скажем, смена гнома2 на гнома 3 или переход кнопок управления окном слева направо при апгрейде убунты на новую гномовую?

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

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

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

Что меня всегда поражало в фанатах линкуса, так это тоталитарные замашки. На словах все за свободу, но как дело доходит до практических вопросов, то сам Иосиф Виссарионович позавидовал бы, каждая софтина, будь то дисплейсервер или аудиоплеер должна быть безальтернативной, если кто-то взялся писать свою, то его последним м**аком считают, какого хрена ты пишешь свой велосипед, иди лучше правь баги в %projectname%. Если программист или мейнтейнер не дай бог прекращает поддержку какого-нибудь говна мамонта, то вой поднимается хоть святых выноси. У меня на этот счёт такая теория: видимо где-то на уровне подсознания существует многотысячелетнее убеждение, что если кто-то тебе делает что-то бесплатно, то он - раб, а ты - господин, и поэтому можешь с ним обращаться так, как ни с одним нерадивым наёмным рабочим себе не позволишь.

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

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

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

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

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

Если вам нужен нормальный менеджер паролей, это должен быть плагин к дисплейсерверу

Интерфейс для плагинов уже узаконили? Или для каждого из «маргинальных» или «специальных» дисплейсерверов плагин придётся лепить отдельно?

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

Wayland это мертворождённый продукт, время это доказало. Он был рождён в 2009-2010 году, когда директору Red Hat моча в голову ударила. Как и остальные продукты того времени: Systemd был рождён из-за ссоры с Canonical незадолго до релиза RHEL6. Из-за заморозки перед релизом, Upstart не успели удалить, но выключили его по умолчанию.

Линуксоиды, подскажите, в каком дистрибутиве есть libopenvg.so (или что-то похожее)?

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

Ну-ну :).

Интерфейс для плагинов уже узаконили? Или для каждого из «маргинальных» или «специальных» дисплейсерверов плагин придётся лепить отдельно?

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

В общем, подход стандартный и стабильный Wayland + свой «проприетарный» API для плагинов - это мудрое решение. 99% софта будут использовать Wayland и в кишки системы не полезут, будут работать нормально на любом совместимом дисплейсервере, а те, кому действительно надо что-то специфическое будут писаться под конкретное API. Авторы дисплейсерверов будут спокойно предоставлять доступ ко внутренним функциям, так как будут знать, что в случае чего спокойно смогут поломать совместимость с расширениями, не ломая при этом нормальный софт. Авторам плагинов/расширений тоже относительно неплохо: если есть одна вменяемая линейка версий, пусть даже не совсем совместимых, сложность поддержки терпима.

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

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

Они мониторили ситуацию с Санками, прикидывали что там у макОС, вот и ударило. да еще и взрывной рост коммерческих ДЦ.
+ Канониклы начали брыкаться и гнать более лучший продукт для мелких клиентов.

сделай сам эксперимент и посмотри (но в дополнение к этому его и двигать тоже могут, да)

Хохма в том, что если провести эксперимент в гномовом терминале, то всё так, по умолчанию вправо вниз, а если не помещается по одной из осей, то по ней в другую сторону. А вот в firefox, то поведение будет компромиссным. По вертикали всё так, вниз или, если близко к краю экрана, то вверх. А вот по горизонтали как я написал, если вдазит, то справа от курсора, а если край экрана близко, то просто сдвинуто влево, чтоб влезло.

В общем, подход стандартный и стабильный Wayland + свой «проприетарный» API для плагинов - это мудрое решение. 99% софта будут использовать Wayland и в кишки системы не полезут, будут работать нормально на любом совместимом дисплейсервере, а те, кому действительно надо что-то специфическое будут писаться под конкретное API.

Это просто шедевр, схороню.

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

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

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

Лучше сейчас отойти в сторонку от айти, лол.

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

Сломать работающую систему, убить стандартные решения, и при этом с причмокиванием говорить про «мудрое решение» - это что-то.

Пословицу «лучшее - враг хорошего» придумали задолго до вейланда и даже до иксов.

И потом к чему эта патетика? Даже если кто-то заставляет вас работать в вейланд сессии, «убили» там самую малость, либо то, что уж откровенно дыряво (как работа в иксах из под рута, и то включается одной командой) или то, что без настоящего xorg не работает, а те, кто могут адаптировать не хотят этим заниматься (как работа glx на нвидиа блобе). Даже грязные иксовые хаки работоспособны: для определения, работает ли программа через вейлэнд можно использовать xeyes, если при движении над окном глаза продолжают следить, значит это xwayland.

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

мне придется в N-ый раз напомнить, что то поведение контекстных меню, о котором я говорю, повторяется в винде и емнип в макоси

мне даже интересно стало: у каких таких аборигенов меню в обязательном порядке обрезаются по окну, а не по экрану, или же не могут быть выставлены программой с 4-х сторон от курсора

поэтому твой отсыл к «чтоб было как раньше и никто даже не догадался, что у нас тут больше не xorg» явно неуместен, и является попыткой подменить мою тему обсуждения: кроссплатформенный gui vs. wayland

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

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

ну так честно скажи: вейлянд это регресс, но хомячки его стерпят так же, как и рабы ред хат стерпели переход с гнома2 на гном3

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

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

отгораживаться от возможных троянов надо не хилым заборчиком из каких-то костылей, а запуском подозрительной программы (или, для параноиков, просто другой программы) под другим user id

в частности, безопасность дисплей-сервера должна позволять тот же доступ, как в иксах внутри одного user id, и ограничивать доступ с другим user id

как с этим в вейлянде? можно ли из под user_id_2 создать окошко, которым полностью или частично перекрыть окошко проги под user_id_1?

плагин к дисплейсерверу

хотя бы концепция плагинов к дисплей-серверу где-то изложена?

ну там что они могут, что не могут, как (через что) взаимодействуют, какие права доступа и т.д.

(кстати, по-русски дисплей-сервер лучше писАть через дефис, а не слитно)

Вообще не понимаю, как люди с ними работают.

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

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

ставиться

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

Попался на неграмотности, книгописец.

Обоснуй-ка?

Спасибо, я всё понял. Против позиции «любой недостаток wayland можно исправить специфическим костылём в дисплей-сервере» ничего особо и не возразишь. Действительно же можно. Я только не понял одну маленькую вещь: а зачем нужен wayland.

Вот, рассмотрим гипотетическую ситуацию: есть дисплейные серверы К и G. Чтобы можно было нормально работать оба обмазаны толстым слоем из расширений. Причём К-расширения не работают в G-сервере и наоборот. Стандартов-то нет. И, соответственно, разрабатывать программы нужно чётко под К или G или даже под их дистрибутивоспецифичные сборки. Так вот, а что нам даёт тот факт, что К и G имеют 10% общее подмножество в виде wayland?

мне придется в N-ый раз напомнить, что то поведение контекстных меню, о котором я говорю, повторяется в винде и емнип в макоси

А я вам привёл пример firefox и thunderbird, которые это нарушают. И всем пофиг. Никто даже не замечает. Вот ни в жизнь не поверю, что вы никогда эти программы не запускали, а значит тоже не заметили, тогда же не надо было придумать оправдание ненависти к wayland'у.