LINUX.ORG.RU

Wayland 1.25

 ,


0

3

Доступен стабильный выпуск Wayland 1.25. Основные изменения касаются документации, удобства разработки и небольших расширений протокола.

Изменения:

  • документация в текстовом формате преобразована из DocBook в mdBook;
  • полностью документированы:
    • XML-диалект Wayland (как писать протоколы);
    • модель обновления содержимого (как клиенты отправляют буферы);
    • управление цветом (color management).
  • новый атрибут «frozen» для интерфейсов, у которых несколько родительских интерфейсов;
  • новый запрос wl_surface.get_release для коллбэков освобождения буфера при каждом подтверждении транзакции;
  • новая функция wl_display_dispatch_pending_single() для отправки одного события;
  • вывод WAYLAND_DEBUG теперь раскрашен, при включении отладки через переменную окружения WAYLAND_DEBUG;
  • исправлены ошибки.

>>> Описание протокола

>>> Скачать

>>> Подробности на freedesktop.org

★★★★★

Проверено: dataman ()
Последнее исправление: dataman (всего исправлений: 2)
Ответ на: комментарий от vbr

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

Так это не работает. Масштабировать этим ты сможешь то что и так масштабируется by design + немного векторной графики.

Смасштабируй диагональную линию к примеру.

windows10 ★★★★★
()
Ответ на: комментарий от vbr

Здравому смыслу.

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

Но это не реализация

Это реализация протокольного слоя.

Реализация в тулкитах, в композиторах и тд.

Это бизнес-логика.

liksys ★★★★
()
Ответ на: комментарий от iSage

ломающийся копипаст

про остальное не скажу, но вот это вроде работает нормально уже давно.

запомнить позицию окна и умирание всего десктопа при полном заполнении видеопамяти

Про позицию не скажу потому что у меня тайлинг, а про заполнение видеопамяти, не замечал такого на невидии. Хотя может и можно как-то добится.

Loki13 ★★★★★
()
Последнее исправление: Loki13 (всего исправлений: 1)
Ответ на: комментарий от Shadow

Очень надеюсь, что благодаря зонам многооконный gimp а ля Фотошоп mac os вернут.

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

Loki13 ★★★★★
()
Ответ на: комментарий от windows10

Смасштабируй диагональную линию к примеру.

А ещё и проходящую через 2 монитора с разным DPI.

Loki13 ★★★★★
()
Ответ на: комментарий от liksys

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

kneedeep
()
Ответ на: комментарий от Loki13

Чтобы что? Как одно окно на несколько дисплеев разнести? Х..ня.

Shadow ★★★★★
()
Ответ на: комментарий от windows10

Так это не работает.

Именно так это и работает.

Масштабировать этим ты сможешь то что и так масштабируется by design + немного векторной графики.

Т.е. 100% контента.

Смасштабируй диагональную линию к примеру.

Не важно, какая линия. Любая линия будет нарисована идеально.

vbr ★★★★★
()
Ответ на: комментарий от vbr

Именно так это и работает.

Нет не работает.

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

Где у тебя будет затык - я заранее знаю.

Т.е. 100% контента.

Нет конечно. Более того, ты даже ШРИФТ не весь можешь увеличить или уменьшить без мыла.

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

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

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

Когда будешь рисовать hello world, о котором я тебя попросил - попробуй текст сделать в полтора раза больше (в css и gtk это {text-size: 1.5em;}), и в полтора раза больше изображение - увидишь о чем я.

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

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

Не важно, какая линия. Любая линия будет нарисована идеально.

Математический алгоритм рисования линии с тобой не согласен. Будет лесенка: https://ibb.co/TBPstmQN

Жду твой hello world с реализацией идеи.

windows10 ★★★★★
()
Последнее исправление: windows10 (всего исправлений: 4)
Ответ на: комментарий от firkax

Ребята, ну чо вы сопротивляетесь то, а? Дистры голодные, Редхат заносит дистрам. Б — бизнес.

deep-purple ★★★★★
()
Ответ на: комментарий от SkyMaverick

Там хитро - зоны находятся во владении композитора. Т.е...

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

deep-purple ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.