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

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

Бывает. И это косяк у которого есть фамилия, имя и отчество. Главное чтобы менеджеры не пытались по факту объявить это новой нормой... Опять же, если нет веской причины делать именно так.

В итоге протокол оперирует сферическими конями в вакууме. И это я только мельком копнул, уверен, там дальше будет еще больше.

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

Ты почитай вообще спецификацию Redfish

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

Systemd так же и делает.

Да как то по нему не видно. Он именно что развесистая хрень, пытающаяся захватить весь мир, и по итогу одновременно и слишком сложный, и недоделанный в самых базовых вещах. Например недавно заметил что команды выключения снова переделали, и вроде бы стало как надо, но блин, 250 сраных версий на это?! КАК они это делают?

на нём можно программировать и вообще на нём весь юникс собран

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

работало во многом лучше системд

И близко нет, по причине описанной выше.

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

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

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

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

И всё это ***ство длилось что то не более 5 лет, после чего все прочие кроме Х.орг-совместимых сдохли и туда им и дорога.

Больше, больше.

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

Окей. Можешь начинать.

И вайланд точно так же не собирается её решать

Он ее УЖЕ решил, алло. Это прямо сейчас работает во всех десктопных композиторах. Я прямо сейчас этим пользуюсь: один монитор на 4к и с масштабированием 300%, а другой 2К со 150%, и ничего нигде не мылит.

никто не хочет последовательно двигаться к векторной отрисовке

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

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

Можешь почитать только те аспекты, которые воспроизводят IPMI BMC. Ты наверняка с этим знаком, будучи админом, хехе. Тогда больше минут 15 не потратится.

по итогу одновременно и слишком сложный, и недоделанный в самых базовых вещах

Это чушь, как мы уже выяснили. Просто названия вещей не соответствуют твоим ожиданиям, вот ты и бесишься.

команды выключения снова переделали

Что конкретно опять тебе не нравится? Что переделали?

Он ее УЖЕ решил, алло. Это прямо сейчас работает во всех десктопных композиторах. Я прямо сейчас этим пользуюсь: один монитор на 4к и с масштабированием 300%, а другой 2К со 150%, и ничего нигде не мылит.

Если ты включил масштабирование 300% на 4K - значит ты слепая курица, поэтому дальнейшие твои рассуждения о том что мылит а что нет можно смело игнорировать. При таком зрении мылится все и то что там дополнительно подмылит вейланд не сиграет роли.

Сижу на 3К 14" без масштабирования - включал оное говно только когда тестировал фокс и было подозрение что глючит именно масштабирование(не подтвердилось) - и мылит оно только в путь. Когда целочисленный фактор типа 300 - в принципе более менее, но когда даем дробный - 105% какие ниюбудь - сущий трэш. И оно в принципе не может не мылить.

поэтому дальнейшие твои рассуждения о том что мылит а что нет можно смело игнорировать

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

Я ношу очки на постоянке, и отлично в них вижу. А масштабирование у меня выкрочено, потому что мой 4K - это огромный телевизор для игр, и интерфейсы на нем должны хорошо читаться. На 2K же мне просто комфортно читать крупные буквы с большого расстояния, чтобы не пялиться в монитор в упор.

Когда целочисленный фактор типа 300 - в принципе более менее

Ну вот, и зачем было выпендриваться? Ты же просто в итоге подтвердил мое заявление.

когда даем дробный - 105% какие ниюбудь - сущий трэш

Разумеется. Но это касется только очень незначительного скейлинга. 150% работает отлично.

И всё, добро пожаловать в адок преобразования форматов - парсинг и форматирование.

...для чего тоже есть свои инструменты.

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

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

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

Больше, больше.

Разве? В ~2000 году по слухам проблемы уже практически рассосались, а в 95-м графические интерфейсы ещё были малополулярны. В любом случае в 2006 всё уже работало как часы и на 2 головы лучше чем вайланд сейчас.

Он ее УЖЕ решил, алло. Это прямо сейчас работает во всех десктопных композиторах. Я прямо сейчас этим пользуюсь: один монитор на 4к и с масштабированием 300%, а другой 2К со 150%, и ничего нигде не мылит.

Так а где здесь произвольное масштабирование? Где 113% или 169,73%? Да и 150% тоже местами мылит а местами нет, причём нет уверенности что до сих пор не делает преобразования х3 делить на 2.

то растровые проблемы всё равно надо решать, и пусть уж лучше всё будет растром.

Нет, растром должно остаться исключительно то что можно делать только растром. И это совершенно точно не шрифты и не тулкиты и уж точно не рамки для окон как в КДЕ6. Чёрт, там и так css/qml головного мозга, откуда там вообще растр остался? И что мешает поставлять все растры темы оформления в 1000dpi и перестраивать масштабирование в кеш под указанные в конфиге масштабы?

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

Можешь почитать только те аспекты, которые воспроизводят IPMI BMC

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

Ты наверняка с этим знаком, будучи админом, хехе.

Но ты прекрасно знаешь что это не так. А значит оценка в 15 минут это сферический конь в вакууме весом 1кг и ростом 1 метр.

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

Что конкретно опять тебе не нравится? Что переделали?

Мне не нравится что они придумали что то жопорукое вроде systemctl shutdown -h now для выключения, а systemctl poweroff/halt были но приводили к зависанию с хорошей регулярностью. И прошло больше 10 лет прежде чем это починили, хотя крайне странно что этого не было изначально. Это к вопросу стабильности и грамотности архитектуры - там у руля изначально был шизофреник и все должны под него подстраиваться, причём наследовать всю эту чушь как святое легаси.

Просто названия вещей не соответствуют твоим ожиданиям

Да, глупо изобретать тайный и уникальный язык для выполнения простейших базовых вещей. Кто то просто тешил своё ЧСВ, и это просто очевидно во всём что касается Поттеринга.

Ну вот, и зачем было выпендриваться? Ты же просто в итоге подтвердил мое заявление.

Потому что 300% это вообще не дробное и даже не слишком то масштабирование. Если dpi выше сотни то можно просто снизить разрешение в 3 раза и не заметить разницы пока не подойдёшь к 4К телевизору в упор.

Разумеется. Но это касется только очень незначительного скейлинга

Там изначально, на уровне протокола версии 0.1 не должно было быть никакой разницы между 200, 150 и 105%. В противном случае тебе гарантированы костыли и косяки в истеричных попытках натянуть сову на глобус.

…для чего тоже есть свои инструменты

Пока тебе не понадобится что-то сложнее выкусывания столбца из табличных данных - всё это отлично работает.

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

То, что где-то еще хуже - не оправдание.

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

Потому что далеко не всё ложится на формат «просто текстовое поле». Структурированное логгирование, например, не просто так изобрели. За пределами локалхоста, это, конечно, далеко не очевидно.

Так а где здесь произвольное масштабирование?

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

В любом случае в 2006 всё уже работало как часы и на 2 головы лучше чем вайланд сейчас.

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

Нет, растром должно остаться исключительно то что можно делать только растром.

Нет, не должно. Это не дает никаких плюсов, зато плодит сущности без необходимости. Вместо одного механизма отрисовки интерфейса у тебя появлятся зачем-то два.

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

Этот ответ принципиально противоречит постановке задачи.

Нет. Смотришь те части, которые интересуют, и делаешь выводы.

Разве что ты не знаешь, что такое IPMI BMC (что в очередной раз подтвердит то, что никакой ты не админ).

твои претензии могут вообще не относиться к Редфишу

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

Но ты прекрасно знаешь что это не так.

Прекрасно знаю, что ты не админ? Конечно, знаю. Я так, подстебываю.

приводили к зависанию с хорошей регулярностью

Какие-то былины хладные. Halt всю дорогу даже на SysV приводил просто к остановке ядра без отключения питания через ACPI. Для нормального выключения всегда использовался shutdown -h now или poweroff. На systemd эти утилиты входят в sysvcompat и дергают само systemd, который, собственно, и управляет выключением.

Так что скорее всего ты делал halt и не понимал, почему всё работает так, как работает (как в случае с mask и disable, лол).

Если dpi выше сотни то можно просто снизить разрешение в 3 раза и не заметить разницы пока не подойдёшь к 4К телевизору в упор.

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

Там изначально, на уровне протокола версии 0.1 не должно было быть никакой разницы между 200, 150 и 105%.

Ее и нет. Я уже выше писал: в вяленде масштабирование работает не так, как думаешь ты или Qui-Gon. Когда ты выставляешь масштаб, композитор отдает эту настройку тулкиту, и тулкит рендерит в правильном разрешении с учетом масштаба.

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

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

Ее и нет. Я уже выше писал: в вяленде масштабирование работает не так, как думаешь ты или Qui-Gon. Когда ты выставляешь масштаб, композитор отдает эту настройку тулкиту, и тулкит рендерит в правильном разрешении с учетом масштаба.

Это в твоем воображении. Когда у тебя окно наполовину на одном мониторе наполовину на другом - хрен что твой тулкит сделает.

Это в твоем воображении.

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

Когда у тебя окно наполовину на одном мониторе наполовину на другом - хрен что твой тулкит сделает.

Нет.

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

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

Но это всё меркнет перед тем, что иксы так не могли и до сих пор не могут, поэтому все твои попытки выставить это как недостаток я списываю, как типичное лукавство от иксофанатика.

Пока тебе не понадобится что-то сложнее выкусывания столбца из табличных данных - всё это отлично работает.

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

За пределами локалхоста, это, конечно, далеко не очевидно.

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

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

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

Вин7 кстати вообще ничего не шакалит в 125%. В отличии от самых прогрессивных.

а в иксах не решена совсем

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

Это не дает никаких плюсов, зато плодит сущности без необходимости

Там уже с первой оконной системы для юниксов 2 отдельных сущности, а до сих пор не забытая тема иконок Кристал в 2008 году существовала в виде КристалSVG, полностью векторного варианта. А на данный момент гтк и кутэ являются векторными тулкитами, как и 99% софта в линуксах. Растровые шрифты тоже выпилены отовсюду. Может пора что то сделать с оставшимся 1% и прекратить шакалить битмапы из за неспособности внятно передать приложению 2 цифры?

А в иксах масштабирования как не было, так и нет.

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

В итоге это дает ровно тот же результат, как если бы у тебя весь интерфейс был векторным:

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

Смотришь те части, которые интересуют, и делаешь выводы.

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

Получилось то, что получилось, потому что так получается всегда.

С ssh и http получилось совсем не как всегда. Да и с Х11 тоже. У него куча недостатков, буквально 100% изначальной спецификации не используется, но это не мешает ему работать лучше вайланда и по части функционала, и по части стабильности и по борьбе с фрагментацией экосистемы.

Halt всю дорогу даже на SysV приводил просто к остановке ядра

Где? Точно не в деб-подобных и не в генту. Вроде бы даже не в Федора-подобных и не в Мандриве, но насчёт последней не уверен.

Скорее всего я не понимал почему poweroff не делает poweroff и почему shutdown так сложно прописать что -h now является поведением по умолчанию если не указано дополнительных аргументов.

Ее и нет.

Ой не надо. Вайланд изначально ничего не знал ни про какое масштабирование потому что красношпки ни с каким QT не хотели договариваться о нём и пилили уникальную гномо-реализацию, даже не под вайланд а под GTK3/X11. Которая только недавно научилась делать 150%, 125% для неё вообще новинка, а 105% они даже слышать не хотят. Дробное масштабирование в вайланд пропихнули другие композиторы, тяжело и с боем и поэтому до сих пор сыро и криво.

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

Т.е. примерно всегда. Шрифты TrueType придумали в 1980 году и я просто не застал линуксов с растровыми. На HD-экранах это уже не было проблемой да и третепни и атомы прекрасно справлялись со сглаживанием и хинтингом.

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

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

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

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

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

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

В С++ тоже не встроено инструментов для работы с таблицами, но это не мешает писать sql-базы данных

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

Можно было например не валить логи в общую свалку.

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

На практике юзер может обойтись вообще без масштабирования

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

Вин7 кстати вообще ничего не шакалит в 125%. В отличии от самых прогрессивных.

Не ври. Кеды у меня тоже ничего не шакалят, потому что это 1/4.

А в иксах можно задействовать виртуальное разрешение

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

Так и проблемы с его отсутствием тоже нет.

Ты опять выдаешь желаемое за действительное. Прямо сейчас 2K и 4К-экраны у ноутбуков стали нормой, и работать на них без масштабирования невозможно.

В отличии от масштабирования и HDR сетевым пробросом я пользовался потому что нужно было.

сетевым пробросом я пользовался потому что нужно было

В вяленде сетевой проброс отлично работает, называется waypipe. Пользуйся на здоровье.

Нет не даёт, потому что тулкит и приложение векторными рисует не все элементы а только те что у него векторные

Нет, дает. Ты просто не понимаешь, как это устроено. Все элементы внутри кода, по сути, векторные: декларируется элемент, его размеры, свойства, положение. Потом поверх него наворачиваются декларативные стили. Дальше всё зависит от темы оформления. Все современные темы под Qt векторные. Я специально переводил свою древнюю растровую тему QtCurve на Kvantum, потому что последний - векторный, и это великолепно работает с масштабированием.

Может пора что то сделать с оставшимся 1% и прекратить шакалить битмапы из за неспособности внятно передать приложению 2 цифры?

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

Всё работает буквально так, как ты хочешь, но сам этого не осознаешь.

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

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

С ssh и http получилось совсем не как всегда. Да и с Х11 тоже.

Потому что ты не знаешь историю. Их писали БУКВАЛЬНО как systemd: сначала код, допиливание-перепиливание, потом стандартизация. А ты хочешь сначала годы проектирования, а потом пук в лужу, потому что спецификация нежизнеспособна.

Где?

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

Вайланд изначально ничего не знал ни про какое масштабировани

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

Которая только недавно научилась делать 150%, 125% для неё вообще новинка, а 105% они даже слышать не хотят.

Это проблемы конкретно гномовского композитора, ограничений в протоколе нет. На кедах я сейчас поставил 105% и всё работает.

поэтому до сих пор сыро и криво

Нет, всё отлично работает. Пользуйся нормальными гуями.

Т.е. примерно всегда.

Нет.

когда приложение, тулкит и вайланд не договариваются

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

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

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

вообще началась позорно недавно

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

Когда в иксах сделают лучше - тогда и поговорим.

он просто получает масштаб от композитора … вайланд будет извращаться в меру своей извращённости

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

Как иксофанатик заявляю - в Х11 данной проблемы в принципе невозможно.

Да, потому что иксы в принципе не могут масштабирование.

Как иксофанатик заявляю - в Х11 данной проблемы в принципе невозможно

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

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

Как мне сделать указанное в иксах? Ну-ка?

Ты меняешь показания. Твой вопрос был Проект Xfce4 разрабатывает собственный Wayland-композитор (комментарий)

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

У меня тоже была пачка проблем, которые мне мешали жить. Что-то я пофиксил сам, за что-то заплатил, чтобы пофиксили.

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

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

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

наверное, что-то мешало

Опять намёки, а конкретных причин, делающих реализацию невозможной, опять не озвучено.

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

«Корреляция как причинно-следственная связь» и «после этого — значит по причине этого» не случайно одни из самых распространённых логических ошибок. От апелляций к корреляциям просто несёт манипуляциями.

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

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

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

Согласен, не опровергает. Согласен, мои примеры статистически не значимы. Только мои примеры взяты из реальности. А твои вероятностные оценки в теме не отметились.

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

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

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

Ты меняешь показания.

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

Попробуй еще раз, на этот раз с фактами.

Но ты не пофиксил дробное масштабирование в иксах.

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

И с чего ты решил, что запросы кого-то-там внезапно что-то значат?

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

Как я уже говорил, запрос ровным счётом ничего не значит.

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

Опять намёки, а конкретных причин, делающих реализацию невозможной, опять не озвучено.

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

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

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

Протокол с зонами (смержили неделю назад) решает этот вопрос. В иксах - надо переделывать всё.

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

Нет, это заключение на основе опыта.

Попробуй еще раз, на этот раз с фактами.

Мой ответ полностью объясняет причины. Если ты считаешь, что были какие-то другие причины, приведи их.

Удивительно, правда?

Нет, не удивительно. Было — ты заюзал. Не было бы — страдал молча.

и запросы порешали.

Есть ли прямая связь между запросом и появлением решения? А то вот у меня есть запрос на неморгающее окно Firefox, а решение уже четыре года что-то не случается.

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

Вы это кто? Во-первых, я не видел хоть какого-то исследования на эту тему кроме голословных заявлений. Во-вторых, корреляция не гарантирует прямую связь. Нет никакого «обязательно». Часто не находится.

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

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

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

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

А почему у меня получилось?

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

Нет, это заключение на основе опыта.

Неубедительно.

Мой ответ полностью объясняет причины.

Нет. И ты не предоставил ссылок.

Было — ты заюзал. Не было бы — страдал молча.

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

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

Сколько еще людей с этим столкнулось?

Вы это кто?

Мы с тобой и с Rootlexx

я не видел хоть какого-то исследования на эту тему кроме голословных заявлений

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

Озвучить вы её почему-то не хотите. Видимо, очень секретная причина.

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

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

Удивительно, что ты этого не понимаешь. Или понимаешь, но просто прикидываешься веником.

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

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

поиск и агрегация работают быстрее и легче

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

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

Ага, то есть отличное масштабирование, которое есть в вяленде, НИНУЖНО

В иксах есть то, что заменяет «отличное масштабирование» в 99% случаев, так что я ещё ни разу не столкнулся с ситуацией когда мне его не хватало, а ведь я где то примерно с 2016 года сижу в масштабах от 105 до 130%. А вот возможностями глобального позиционирования окон пользуюсь регулярно. Если точнее - каждый раз когда музыкальный плеер начинает новый трек. Ну и ещё иногда кроме этого, например когда сторонняя утилита выбрасывает список окон под курсор.

Кеды у меня тоже ничего не шакалят, потому что это 1/4

У тебя 5-е или 7-е кеды? 6-е шакалят, хоть и по мелочи, но достаточно чтобы зацепился взгляд.

Гланды через жопу тоже можно удалять.

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

и работать на них без масштабирования невозможно.

2К это +9% к fullHD, который у меня появился в 2016 (причём ноутбучный 15") и под который я легко и непринуждённо настроил окружение gtk2/qt4/Х11. А для 4К тогда пришлось бы искать специальную тему... ПЦ проблема, минут на 10-20!

Ты говоришь так, как будто рост экранов в экосистеме Х11 со времён 800х600 никто не замечал. И как будто во второй половине 2010-х внезапно проснулись, и батюшки, 1080p на дворе... Надо что то делать, но мы не можем... А ведь в самом корне Х-протокола векторы и передача dpi монитора и стандартизованного шрифта всем клиентам чтобы они рисовали под правильный размер - внезапно ровно то самое, что преподносится как инновация в вайланде. Инновация, которой всего то лет 40.

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

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

...а потом поверх него натягивается текстура немого не того разрешения в которое её надо натянуть.

Всё работает буквально так, как ты хочешь, но сам этого не осознаешь.

Ключевое слово здесь «всё». Нет, не всё.

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

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

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

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

А второе - утилита (что то мне подсказывает - весьма простая), которая будет делать поиск по логам.

И снова нет. Когда логов много, и они просто свалены по файлам, поиск в них будет работать крайне медленно.

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

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

где то примерно с 2016 года сижу в масштабах от 105 до 130%

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

В иксах есть то, что заменяет «отличное масштабирование» в 99% случаев

Нет этого в иксах.

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

Да, и работает это как фаллбек. А в иксах шакалит всегда бай дизайн. Разницу чувствуешь?

У тебя 5-е или 7-е кеды? 6-е шакалят, хоть и по мелочи, но достаточно чтобы зацепился взгляд.

Седьмых кед не существует. У меня шестые, всё прекрасно.

легко и непринуждённо настроил окружение

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

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

Пруфы, что «решается», в студию. И перечисли, что конкретно развалилось.

…а потом поверх него натягивается текстура немого не того разрешения в которое её надо натянуть.

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