Проект Wakefield — нативный Wayland в OpenJDK

Разработчики понимают объем работ

Вроде бы у других фреймворков особых проблем не было..

Я так понимаю для Swing?

Я так понимаю для Swing?

На странице проекта отмечаются, например, java.awt.Robot, screensharing и совместимость с X11.

Проект сырой, и информации пока толком нет, но само наличие такой инициативы радует. Поддержка Wayland в Java, мягко говоря, отсутствует – и это проблема, которую важно решить.

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

но не унывают

Это главное. Главное не знать, что всё уже запилили: https://github.com/petabyteboy/caciocavallo

Разработчики понимают объем работ, которые могут занять вплоть до нескольких лет

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

Смотря какого. Подозреваю, что в данном случае надо вносить правки в JVM, а это C++.

Еще раз, как биндинги к самым базовым функциям протокола помогут реализовать захват экрана и скриншоты, исправить проблемы с запуском приложений в XWayland?

Так блет. Какой нахер захват экрана и xwayland? Cacio реализует AWT toolkit для wayland. Если его использовать вместо обычной реализации, то твоя ява запустится под вяленым. А с захватом экрана и скриншотами идите к своим вялым композиторам.

Чушь какая-то. Приложение хочет делать скриншоты, технические средства для этого есть. На иксах тулкит предоставляет такую возможность, на Wayland – нет. Логично такую возможность предоставлять.

Ты дурачок что-ли? Robot использует awt для снятия скриншотов. Cacio реализует awt бекенд для wayland. Что тебе ещё нужно?

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

Wayland сервер на Java никто не делает? X11 сервер был.

Разработчики понимают объем работ, которые могут занять вплоть до нескольких лет

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

Раз я дурачок, то вперед, пиши на Java программу для снятия скриншота экрана на Wayland. Жду.

Есть такое на Scala.

А с захватом экрана и скриншотами идите к своим вялым композиторам.

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

Уже давно всё через PipeWire.

. А с захватом экрана и скриншотами идите к своим вялым композиторам.

есть следующее мнение

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

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

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

например, если бы Google хотел использовать на андроиде Джаву, то им бы пришлось реализовать для андроида полный интерфейс на AWT/Swing, даже если бы этот интерфейс использовался ровно в 0 реальных приложений

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

AWT, включая скриншоты и автоматизацию управления окнами, являются частью этой минимальной обязательной функциональности

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

Несколько лет назад я задавался тем же вопросом (как управлять окнами) и пошел разбираться

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

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

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

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

В общем, коллектив неуверенных в себе людей посоветовал мне взять в руки Си, GObject Introspection и выколупать нужные мне функции наружу рефлексией, оформив в виде dll-ки. Потом её обвязать джаваскриптовым АПИ. И укатать в Gnome Shell Extension. После чего подключить к этому экстеншену общение через DBus, и дальше использовать как апи DBus. И вот его уже звать из своего приложения.

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

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

Wayland — одна из наиболее успешных диверсий в IT. На этот проект уже слили тысячи человеколет и сольют ещё десять тысяч.

человекотлет

Понятия не имею, как это делать гномоспецифичным методом.

На wlroots есть эталонная реализация grim, написанная на простой и читаемой сишке.

$ wc -l grim/*.c
   57 grim/box.c
   96 grim/buffer.c
  126 grim/cairo_jpg.c
   96 grim/cairo_ppm.c
  586 grim/main.c
   68 grim/output-layout.c
  213 grim/render.c
  121 grim/write_png.c
 1363 total

Кросскомпозиторным способом на данный момент являются порталы. У org.freedesktop.portal.Screenshot свои изъяны, он дампит скриншот в промежуточный файл и возвращает URI этого файла, что приводит к неприятным задержкам. Тем не менее, это рекомендованный способ.

Далее, можно дергать PipeWire. Далее, можно дергать платформоспецифичные протоколы.

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

мне бы не скриншоты, а управление окном: перемещение, изменение размеров, сворачивание-разворачивание, и самое главное - перехват (существующих) и рассылка (созданных тобой новых) событий типа кликов мышкой и нажатий клавиатуры, желательно с детализацией какой именно девайс произвёл данный клик (если речь идет о USB HID с бесконечным количеством кнопок). Иногда хочется получить структуру виджетов внутри окна (так умеет WinAPI, там каждый «тяжелый» элемент интерфейса - это считай отдельное окно с отдельным идентификатором). Иногда хочется порисовать на поверхности другого окна (например, вывести счётчик FPS в игру, которая так не умеет, или что-то такое). Мне это нужно для автоматизированного управления из одного приложения всеми другими.

а управление окном: перемещение, изменение размеров, сворачивание-разворачивание

Протокол wlr-foreign в wlroots.

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

libinput, ydotool

Иногда хочется порисовать на поверхности другого окна (например, вывести счётчик FPS в игру, которая так не умеет, или что-то такое).

К сожалению, не смогу ответить.

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

Никак by design. GTK Inspector и аналоги – самое близкое, что есть.

не это нужно для автоматизированного управления из одного приложения всеми другими.

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