Проект Xfce4 разрабатывает собственный Wayland-композитор

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

Ты пробовал на шарпе-то писать?

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

Спасибо. Наверное, можно было бы создать тему с вопросом разбирающимся людям. Мне прям действительно стало любопытно.

В любом случае, это сильно лучше чем то, что есть в иксах.

Но люди выбирают то, с чем им проще/удобнее/привычнее работать и что лучше решает их задачу.

Если пользователи не нужны, то можно и так.

А Qt не юридически опасная технология? Когда кеды возникли, это была 100% проприетарщина.

не юридически опасная технология?

Нет, и никогда не была.

• Первый релиз кед состоялся в середине 1998. Тогда же Trolltech гарантировали доступность Qt для опенсорса.

• В 1999 зарелизили Qt под X11 под собственной свободной лицензией QPL, аппрувнутой FSF.

• В 2000 Qt вышел под GPL.

Легко увидеть, что Trolltech были уже изначально были настроену к опенсорсу доброжелательно, и спустя полтора года Qt даже стал GPL.

Байка про проприетарность Qt уже 26 лет как не имеет ничего общего с действительностью.

пещерный мазохизм с использованием самых неподходящих инструментов

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

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

Нет, это не всегда так происходит. Например, до того как я начал попытки подружить PepperFlash с Firefox, я в интернетах только встречал утверждения, что мол, это невозможно, PepperFlash слишком сильно заточен под Chrome, раз никто не сделал, значит были какие-то причины, и тому подобное. Но технических причин на самом деле не было. Просто. Никто. Не занимался.

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

Речь про контекстное меню? Думаю, причина простая. Не сделали, потому что не сделали.

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

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

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

Не ври, ой не ври! Я помню, какой ор выше гор стоял, когда пульсу только начали внедрять

Речь не про переезд с ALSA на PulseAudio, а про переезд с PulseAudio на Pipewire. Есть ненулевой шанс, что у тебя в системе переезд состоялся, а ты его даже не заметил. И вот это и есть то, что должно происходить. ОС должна становиться лучше без потери функциональности.

Была очень везкая причина отказа в приеме изменений

Расскажи про вескую причину отказа в приёме вот этого патча, например: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1995/diffs

Зачем эти функции вообще в коде?

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

Даже если из 10 будут 9 не по делу, а одна по делу, та, что по делу, всё ещё будет по делу.

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

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

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

Я не знаком со статьёй, про которую ты говоришь. Ссылка есть? Там прямо пишут, что KiCad крашится из-за Wayland?

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

Я об этом и говорю: процесс изначально сломан.

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

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

Стоит только сказать про проблемы иксов - и начинается вой про проблемы вяленда.

Да, и тут позиция Wayland в споре проигрышная. Wayland должен быть лучше иксов по всем фронтам, потому что Wayland позиционируется как решение проблем иксов. Но с решением одних он вносит другие. Причём если с иксами проблемы можно подпереть костылями, с Wayland это становится делать чрезвычайно сложно. Костыли всё ещё возможны, но теперь вместо чего-то вроде kdocker, который я могу использовать в XFCE, мне надо будет мигрировать на KDE? У меня уже достаточно проектов, мне не нужен ещё проект по миграции на другое DE. Мне привычно моё окружение, но основу из-под него весело и с инклюзивностью выбивают.

Мне, как пользователю, надо ехать, а не шашечки. А иксы никуда не едут уже очень давно.

Я понимаю необходимость смены одного ущербного решения на другое ущербное. Но не понимаю радости от нового ущербного. Когда указываешь, что новое — ущербное (хотя обещали, что будет лучше), люди ощетиниваются, и начинают ругать старое ущербное. Заявляют, что вот в новом работает вот это. А когда им говоришь, что в старом тоже работало, начинают огрызаться. Мол, это не удовлетворяет современным реалиям.

О том, что нужно подымать оба разрешения до 2x, нигде не указано.

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

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

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

То есть иногда апскейл? Это ужасно.

Так или иначе, это несравненно лучше, чем то, что есть (точнее, чего нет) в иксах.

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

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

Какие такие разные поверхности? Где техническая возможность?

Просто. Никто. Не занимался… Думаю, причина простая. Не сделали, потому что не сделали.

Удивительно, что за двадцать лет страданий не нашлось никого, кто решился бы починить масштабирование в иксах. Всё можно было, но никто не сделал. А вот в вяленде взяли и сделали. Как же так вышло?..

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

Насколько часто нужно делать скриншоты контекстного меню? Это нужно большинству?

Ну начинается НИНУЖНО. Большинству и глобальное позиционирование окон не нужно, но протокол, тем не менее, делается. Я же говорю: у вас про святые иксы позиция простая: если чего-то нет, то это либо НИНУЖНО, либо МОЖНО СДЕЛАТЬ (но никто почему-то не сделал).

в Gnome под иксами я могу организовать сворачивание приложения в трей, а в Gnome под вейландом — нет.

Я в кедах на вяленде могу использовать дробное масштабирование и не ломать глаза, а под иксами не могу. Что делать будем с этим фактом? Я понимаю, что в иксах МОЖНО СДЕЛАТЬ, но когда это будет сделано? А? А? А? Когда? Между тем, сворачивание в трей уже можно реализовать средствами отдельных композиторов.

Иными словами, в вяленде есть решение перечисленных проблем, а в иксах их нет, но они МОГУТ БЫТЬ (но никто делать не будет).

Речь не про переезд с ALSA на PulseAudio, а про переезд с PulseAudio на Pipewire.

Очень удобная манипуляция - говорить о замене в рамках одного протокола, когда пульса уже проторила дорожку и порешала все проблемы, об которые мог споткнуться пайпвайр. Буквально то, что сейчас происходит с вялендом: он идет так медленно и со скрипом из-за вороха легаси и необходимости со всеми договариваться. Так что сравнения вяленда с пульсой сильно более валидно, чем с пайпвайром.

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

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

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

Да, именно так и работает. Веская причина называется «разработчики положили на линукс и думали, что само рассосется». Не рассосалось.

Я не знаком со статьёй, про которую ты говоришь. Ссылка есть? Там прямо пишут, что KiCad крашится из-за Wayland?

Наслаждайся: Application freezes and crashes: Instability issues specific to the Wayland environment. И прочее, прочее. У всех работает - у них не работает, и виноват вяленд, а не гигатонны легаси-кода.

Это провал Wayland как процесса.

К сожалению, у любителей иксов не нашлось времени, чтобы показать, как надо было сделать. Всё ушло на рассказы о том, как в иксах МОЖНО ЧТО-ТО ПОЧИНИТЬ.

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

Я тебя прекрасно понимаю. Но в моем случае основа отвалилась сама, когда я купил новый ноут, и оказалось, что иксы на нем работают как говно. QtCurve, тему для которого я таскал последние 15 лет от системы к системе, тоже поломался на масштабировании. Но при этом в вяленде мне предложили решение, а в иксах сказали любоваться на протокол и на ВОЗМОЖНОСТЬ того, что это МОЖНО решить. Когда-нибудь. Или вообще никогда. Так что я напрягся и начал проект по переезду: тему с QtCurve переделать на Kvantum, подкрутить конфиги, вот это всё. А что мне еще оставалось делать, ждать, когда иксы попатчат, хотя не попатчили за двадцать с лишним лет?

О таком приёме упоминалось где-то в обсуждениях, когда это расширение предлагали.

Очевидно, это уже неактуально.

То есть иногда апскейл? Это ужасно.

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

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

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

Какие такие разные поверхности? Где техническая возможность?

Посмотри wl_surface. Впрочем, тут я могу ошибаться, потому что я не разработчик вяленда.

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

Вот меня больше всего смущает этот пункт. Причём если проблемы иксов я могу решить костылями(ну, например, скрин контекстного меню через таймаут), то в wayland его проблемы не решаемы и/или требуют больших усилий.

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

Удивительно, что за двадцать лет страданий не нашлось никого

Кстати. А ведь вейланду уже скоро стукнет восемнадцать лет. Но так и не нашлось никого, кто заставит его работать из коробки.

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

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

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

Хм, а точно имеет значение бо́льшая часть окна?

Ну, у меня выглядело именно так. Проверил на текстовом редакторе с выкрученным размером шрифтов, и смотрел, как рендерится глиф.

Но так и не нашлось никого, кто заставит его работать из коробки.

У меня всё работает из коробки.

И да. Пример про пульсу и пайпварь тут очень хорошо подходит.

Нет.

Пульса и пайпварь имели совместимые протоколы, и пайпварь прошла по уже выпрямленным проблемам альсы.

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

Очевидно, что более валидно сравнивать вяленд с пульсой.

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

Во-первых, если у тебя он не работает из коробки, не означает, что он ни у кого не работает из коробки. У меня, например, работает. Во-вторых, как будто Иксы из коробки работали😏

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

Мне вообще кажется, что разделение линуксоидов на сторонников иксов и вяленда во многом базируется на УМВР) Ну ещё с поправкой на некоторую долю сообщества, которая вообще в принципе в штыки принимает любые новшества.

Ну, у меня выглядело именно так. Проверил на текстовом редакторе с выкрученным размером шрифтов, и смотрел, как рендерится глиф.

Хм, и правда так работает. Ну очень странное решение разработчиков KDE как по мне — ведь после масштабирования в сторону увеличения шрифты выглядят… как бы это помягче сказать…

Если вяленд не работает из коробки - проблема с конкретной реализацией композитора. Маловероятно, что проблема кроется именно в libwayland, учитывая, как широко он используется.

Я бы сделал логику поумнее: если окошко вылетает на 1/6 на другой экран - апскейлить, если на 1/3 - рендерить всё в большем разрешении и даунскейлить. Ну или как в гноме.

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

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

Очевидные вещи говоришь.

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

Сферическое API в вакууме почти всегда фундаментально несовместимо со внутренней архитектурой приложения - а то и вообще с реальным миром, потому что оперирует сферическими конями

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

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

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

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

Нет, ты не сможешь нарисовать хороший план, если у тебя нет навыков и опыта трассировки.

Значит в топку это API и надо искать или делать другое.

Это происходит ВСЕГДА при проектировании многофункционального софта.

Не понял сути проблемы.

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

ты не пользовался им сознательно

Абсолютно сознательно, понимая что это косяк, но не видя никакой нормальной альтернативы. Разве что написать своё собственное дерево юнитов и/или свой собственный системд.

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

rrr@raspberrypi:/tmp $ systemctl | grep journal
rrr@raspberrypi:/tmp $

rrr@raspberrypi:/tmp $ systemctl | grep logind
  systemd-logind.service                                                                                                                                        loaded active running   User Login Management
rrr@raspberrypi:/tmp $

rrr@raspberrypi:/tmp $ systemctl list-units | grep journal
rrr@raspberrypi:/tmp $

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

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

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

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

А вот тут не надо. Это ты умудрился «замаскировать» сервис таким образом что он остался загруженным и в состоянии disabled. И да, я это буду тебе напоминать потому что отмазки про «не оттуда копировал» звучат как мем «не в то окно» в icq.

Можешь начать с включения логов

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

Это самый первый и самый важный этап дебага.

Мне не нужен дебаг. Мне нужно чтобы не было никакого дебага. Дебиан это обеспечивает без лишних телодвижений.

Купи себе мак и не мучайся.

Мак такой же концептуально дефектный как и системд. Только ещё и в 3-4 раза дороже чем он того стоит.

Видишь некоторую разницу.

Вижу, что ты не умеешь пользоваться systemctl. Открой для себя systemctl list-unit-files.

даже разработчик не знает как это может сказаться на работе системы

Конечно, не знает. Это должен знать ты, как админ, отвечающий за функционирование сервисов.

это один хрен не заставит эту штуку нормально отключать демонов как в нормальный системах инициации

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

И что мне это даст?

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

Мак такой же концептуально дефектный как и системд.

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

Нет, ты не сможешь нарисовать хороший план, если у тебя нет навыков и опыта трассировки.

Хороший - вероятно нет. Соответствующий стандартам, читаемый, выполняемый и решающий задачу - да, вполне.

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

Это происходит ВСЕГДА при проектировании многофункционального софта.

Не, не всегда. Юниксовый шел и Х11 - отличные примеры как многофункциональный софт был собран из кучи разрозненных компонентов, взаимосовместимость которых не тестировалась. Пока что работает на голову лучше современных альтернатив.

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

А что там перечитывать? Ты сказал что можно запросить типы приводов. Т.е. вот у тебя «там» есть ДВД-привод и есть флешка. В чём проблема угадать что на первый пишем вот эти образы а на второй другие? Ну да, в самом файле-образе действительно не написано куда его писать, ну и что? У человека то нет с этим проблемы, почему нельзя заскриптовать также как это определяет человек?

Ладно, я устал от твоего тупняка. Слепому и глухому невозможно объяснить, как выглядит зеленый слон. Особенно прекрасно, что ты даже не можешь понять, в чем проблема Redfish, и даже отказываешься перечитывать, чтобы въехать в суть проблемы.

И почему я решил, что тебя хоть чему-то можно научить?..

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

Можно шрифтом Брайля.

Но не зеленый же!

⠵⠑⠇⠡⠝⠮⠯⠀⠎⠇⠕⠝⠲

Ладно уж, вдогонку.

Юниксовый шел и Х11 - отличные примеры как многофункциональный софт был собран из кучи разрозненных компонентов, взаимосовместимость которых не тестировалась.

И близко нет.

Юниксовый шелл является очень минималистичным протоколом взаимодействия текстовых потоков данных, если можно так выразиться. Всё, что программы умеют - это stdin, stdout, stderr, переменные окружения и кое-что еще по мелочи. При этом сложности их обработки перекладываются с системы на юзера: как только тебе надо распарсить и преобразовать произвольные данные - начинаются пляски вокруг grep, sed, awk и прочих perl. А то и вообще приходится писать уже полноценный длинный код. В простых случаях это удобно, а вот в сложных - уже не очень. Текстовые потоки это, конечно, универсальный интерфейс, но чем сложнее структура потока - тем хуже его обработка.

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

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

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

В чём проблема угадать что на первый пишем вот эти образы а на второй другие?

В том, что получится созависимая конфигурация двух приводов, а протокол не предусматривает индикацию этого и возможность указать, что «привод занят чем-то, но не образом». В момент, когда ты добавишь образ в один из приводов, они оба становятся в суперпозицию, и если кто-то со стороны посмотрит на конфигурацию, будет не ясно, кто именно получил образ. Более того, любая система управления приводами решит, что это ДВА ОТДЕЛЬНЫХ привода, потому что никакой парности тоже не предусмотрено.

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

Чем дольше смотришь - тем хуже становится. Ты почитай вообще спецификацию Redfish, это же сферический REST в вакууме. Куча service discovery, заявка на окончательность и универсальность, и вот такой вот облом в деталях. С развесистыми протоколами, которые пытаются покрыть весь мир, так получается ВСЕГДА.

А знаешь, как бывает по-другому? Когда сначала пишут реализацию, устаканивают ее, и стандартизируют. Так было, например, с SSH. Ты же любишь SSH? И я люблю. Ну вот, люди написали SSH, убедились, что с ним всё хорошо, получили для него порт 22, а потом написали RFC.

Systemd так же и делает. Исследовали вопрос, написали реализацию, стандартизировали API. Протоколы должны быть либо стандартными и специализированными (с хорошим механизмом структурированных (это важно) расширений, если нужно), либо разрабатываться по приложение, а потом уже от него идти к некой универсальной форме. Другого не дано.

Как же так вышло?

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

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

А миграция на Wayland сама собой в тулкитах произошла, ага.

Ну начинается НИНУЖНО.

Открой эту тему, и поищи, кто первый написал «большинству не нужно». Я просто повторил твои аргументы. :-D

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

Нет, это ничего не значит. И вот тебе пример. У Microsoft есть все ресурсы, чтобы починить поиск в меню Пуск, а он как был кривой годами, так до сих пор кривой. И само меню Пуск, открывая и закрывая которое можно легко и непринуждённо эпично загрузить CPU. У Google — огромные ресурсы, но поиск по истории в Youtube часто фейлится. Часто я не могу найти видео в истории просмотров по ключевым словам. Причём просто прокручивая я его часто и нахожу. Слова совпадают в точности, но поиск не работает. И это Google, у которого поиск это специализация. Так что не нужно пожалуйста этих домыслов. Наличие ресурсов ничего не гарантирует.

святые иксы

Почему ты так зациклился на святости иксов? Я ничего подобного не утверждал. Ты меня ни с кем не перепутал?

Наслаждайся

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

Миграция на другое API, внезапно, требует ресурсов. Ресурсов, которые не пойдут на решение других задач.

Это провал Wayland как процесса.

К сожалению, у любителей иксов не нашлось времени, чтобы показать, как надо было сделать. Всё ушло на рассказы о том, как в иксах МОЖНО ЧТО-ТО ПОЧИНИТЬ.

Не отменяет провал Wayland как процесса.

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

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

«Можно». Когда другие пишут «можно», ты это высмеиваешь. Когда ты сам пишешь «можно», это нормально. Не находишь это каким-то… неправильным?

Но не находишь ли ты вот это постоянные пассажи типа «как же так вышло» манипуляциями?

Нет, не нахожу. Зато твой ответ я нахожу маловероятным, потому что спрос на фичу был.

А миграция на Wayland сама собой в тулкитах произошла, ага.

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

Нет, это ничего не значит.

Напрямую - нет. Но мое предположение совершенно ничем не хуже твоего. Даже чуточку лучше: проблемы иксов все же решались: добавлялись средства динамической конфигурации, отрывался рут и всё такое прочее. Есть все основания считать, что чинили то, что не сломает совместимость. А всё потенциально проблемное не трогали.

если падение воспроизводится на Wayland, но не воспроизводится на X11

Да-да-да, конечно. Как удобно, что ты проигнорировал вот этот пассаж в самом начале:

The following problems are known issues in Wayland protocols or their implementation in desktop compositors, window managers or other layers in the display stack that are beyond our ability to resolve:

И далее идет пункт «Application freezes and crashes: Instability issues specific to the Wayland environment» в соответствующем подпункте. То есть они буквально в своих багах обвиняют не просто абстрактный вяленд, а вообще все композиторы.

Не отменяет провал Wayland как процесса.

Еще раз: пусть апологеты иксов отвлекуться от рассказов о том, как иксы МОЖНО ПОЧИНИТЬ, и покажут, как надо делать правильный процесс.

Заявлять, что старый смеситель протекал, когда речь идёт о том, что новый протекает, просто глупо.

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

• В случае с иксами мне предлагается любоваться на протокол, в котором это МОЖНО починить.
• В случае с вялендом все популярные композиторы дают мне СУЩЕСТВУЮЩЕЕ И РАБОТАЮЩЕЕ РЕШЕНИЕ. Пораскинь мозгами и реши, что я выберу из этих двух пунктов. Почему я должен быть привязан к иксам, которые больше не решают моих проблем?

Не находишь это каким-то… неправильным?

Нет, не нахожу.

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

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

Как там на вялом, калибровку монитора уже прикрутили?

Да, во всех самых важных композиторах это уже есть.

У KWin пока нет своего калибратора, но он поддерживает ICC-профиля, которые можно получить сторонним инструментом. Сам так использую.

Нет, не нахожу. Зато твой ответ я нахожу маловероятным, потому что спрос на фичу был.

Спрос на нормальный поиск в меню Пуск в Windows гораздо больше спроса на возможность скриншотить по нажатию комбинации клавиш открытое меню в иксах. Меню Пуск не чинят. Так что я нахожу твои рассуждения о вероятности и маловероятности необоснованными. Факт есть факт: абстрактный спрос ничего не решает.

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

Никто никогда не измерял количество усилий, которое нужно для первого и второго. Твоё утверждение строится на воспринимаемом количестве усилий.

Есть все основания считать, что чинили то, что не сломает совместимость. А всё потенциально проблемное не трогали.

Это домыслы. Как я уже упоминал, в ситуации с PepperFlash у многих была уверенность в сильной завязке на внутренности Chrome. Причём я это слышал от человека, который хорошо знаком с устройством внутренностей Firefox. Я до сих пор думаю, что он просто не смотрел на API и не проводил анализ самостоятельно.

ты проигнорировал вот этот пассаж в самом начале

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

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

У тебя есть доказательства, что это разработчики KiCad криворукие? Вот я открыл https://gitlab.com/kicad/code/kicad/-/issues/17804, там есть бектрейс, и он показывает, что приложение было завершено внутри GTK. Натурально так GTK просто вызвал exit(). Этого как можно было избежать? Другой какой-то багрепорт был про краш в libEGL. Это иксофанатики поднасрали, да?

Еще раз: пусть апологеты иксов отвлекуться от рассказов о том, как иксы МОЖНО ПОЧИНИТЬ, и покажут, как надо делать правильный процесс.

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

дают мне СУЩЕСТВУЮЩЕЕ И РАБОТАЮЩЕЕ РЕШЕНИЕ. Пораскинь мозгами и реши, что я выберу из этих двух пунктов. Почему я должен быть привязан к иксам, которые больше не решают моих проблем?

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

Это, конечно, МОЖНО сделать, но никто за двадцать лет так и не сделал.

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

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

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

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

Да, во всех самых важных композиторах это уже есть.

А знаешь, в каких DE и WM под иксами можно профиль применить? Во всех. :-D

которые можно получить сторонним инструментом

Инструмент работает под Wayland?

Вот у меня есть ColorHug. Допустим, иксы полностью пропали, ни бинарников, ни сорцов не осталось. Есть только Wayland. Я смогу для монитора профиль сгенерировать?

Спрос на нормальный поиск в меню Пуск

Мне не интересен спрос на меню «Пуск», мне интересно дробное масштабирование.

Никто никогда не измерял количество усилий, которое нужно для первого и второго.

Можешь попробовать начать.

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

Нет, там буквально написано known issues IN Wayland protocols or their implementation in DESKTOP COMPOSITORS. Они говорят именно о серверной части вяленда, которая находится в композиторах, а не о клиентском или библиотечном коде. То есть - валят свои баги на вяленд.

У тебя есть доказательства, что это разработчики KiCad криворукие?

Я не заявлял, что они криворукие. Я говорил, что они обвиняют в своих проблемах вяленд.

Однако от этого твой выбор не перестаёт быть набором костылей.

Мне уже наскучила эта демагогия с твоей стороны.

И это, сюрприз-сюрприз, уже реализовано в Firefox.

Хорошо, почему за двадцать лет никто не сделал это ни в одном тулките? Опять «просто потому что»? Да что ж такое, кругом столько проблем было, но никто ими почему-то не занимался. Вот теми, что не касаются совместимости - занимались, а те, которые могут что-то потенциально сломать - старательно не трогали.

Удивительная логика.

Так в иксах ли была проблема?

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

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

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

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

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

А знаешь, в каких DE и WM под иксами можно профиль применить? Во всех. :-D

Меня, как пользователя KDE, не особо волнует, что под какими-то цугундерными композиторами это не реализовано. В кедах с гномом есть - и подавляющему большинству юзеров достаточно.

Инструмент работает под Wayland?

Да.

Я смогу для монитора профиль сгенерировать?

Да.

Спрос на нормальный поиск в меню Пуск в Windows гораздо больше спроса на возможность скриншотить по нажатию комбинации клавиш открытое меню в иксах. Меню Пуск не чинят. Так что я нахожу твои рассуждения о вероятности и маловероятности необоснованными. Факт есть факт: абстрактный спрос ничего не решает.

Это всё-таки лукавство.

В свободном ПО есть прямая корреляция между запросом на изменения и вероятностью нахождения людей для реализации этих изменений.

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

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

В винде есть - и подавляющему большинству юзеров достаточно.

Невозможно не согласиться.

Я этого не говорил.

Это всё-таки лукавство.

В свободном ПО есть прямая корреляция между запросом на изменения и вероятностью нахождения людей для реализации этих изменений.

А в этом заявлении лукавство просто зашкаливает. Хотя ты пишешь исключительно о наличии корреляции, по контексту видно, что идёт жирный намёк на причинно-следственную связь.

Просто запроса далеко не достаточно. Мне сходу в голову пришло три проблемы¹, которые меня напрягают, на две из которых есть записи в трекерах. Одному из фичреквестов больше 13 лет. И что-то как-то не двигаются. Запрос есть. Где реализация? Где реализаторы?

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

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

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

В Windows же реализация изменений зависит прежде всего от решений менеджмента, а не от желания пользователей.

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

¹ Вот список:

• В Almanah за один день может быть только одна запись, а удобнее было бы иметь возможность делать отдельные записи (чужой фичреквест, старше 13 лет);
• в Firefox при поднятии окна или переключении на рабочий стол с окном Firefox возникает визуальный мусор (мой багрепорт, больше 4 лет);
• в Firefox после перехода на WebRender большие страницы рендерятся по несколько минут (не искал багрепорт), на Basic было быстрее.

А в этом заявлении лукавство просто зашкаливает. Хотя ты пишешь исключительно о наличии корреляции, по контексту видно, что идёт жирный намёк на причинно-следственную связь.

А давай за меня что-то там не выдумывать, хорошо? А то отлично придумал: проинтерпретировать заявление другого человека так, чтобы тебе было удобно его опровергать, а не так, как написано. А ведь именно так — в терминах вероятностей — написано не зря.

Просто запроса далеко не достаточно. Мне сходу в голову пришло три проблемы¹, которые меня напрягают, на две из которых есть записи в трекерах. Одному из фичреквестов больше 13 лет. И что-то как-то не двигаются. Запрос есть. Где реализация? Где реализаторы?

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

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

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

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

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

Я повторю свой вопрос еще раз, мне не сложно.

Мне нужно разное дробное масштабирование без мыла на разных экранах.

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

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

Просто запроса далеко не достаточно. Мне сходу в голову пришло три проблемы¹, которые меня напрягают, на две из которых есть записи в трекерах. Одному из фичреквестов больше 13 лет. И что-то как-то не двигаются. Запрос есть. Где реализация? Где реализаторы?

Это называется «крайность». У меня тоже была пачка проблем, которые мне мешали жить. Что-то я пофиксил сам, за что-то заплатил, чтобы пофиксили. Но проблемы эти были настолько специфическими, что почти никому не мешали (либо мешали, но никто не знал, как это починить).

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

Общественный запрос мало что решает.

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

to liksys , тут где то в треде (лень искать) писал про протокол зон. Его на днях смерджили.

Ну вот, минус одна проблема. Теперь осталось дождаться реализации - много времени это не займет - и всё будет работать.

Оказывается, можно просто решать проблемы, а не только рассказывать, как их можно решить.

Кстати, почитал протокол: а довольно хитроумно придумано.

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

Посмотрим, за реализациями, но, на вид, выглядит интересно.