Hi, So far, it seems native Xlib is a good fit:
https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib It's still a big mess since I'm porting gradually while learning X11. -- Thiago. Em ter., 25 de jan. de 2022 às 12:06, Thiago Milczarek Sayão < thiago.sa...@gmail.com> escreveu: > > I put some thoughts on Linux glass backend and I think a pure Xlib backend > would be the ideal choice. > > Why? > > 1. X11/Xlib is supported by Xwayland, so it will work for decades > (probably). Having two backends to support for one platform would not be > ideal, so sticking with X11 would be the most "compatible choice". I will > probably be forever supported, since many applications rely on it. > > 2. Gdk4 moved away from being a "general toolkit layer" to being a "gtk4 > platform abstraction layer", so many things are missing such as: > - Moving windows; > - Drawing directly on a window; > - Relative window positioning; > - Changing window stacking; > - Pointer warping; > > Glass needs it, so it would be required to use a Xlib call anyways, since > Xwayland currently does not support those operations as well (except > through the X11 compatibility layer). > > Newer gtk3 versions deprecate a lot of functions and make a path to gtk4, > so even gtk3 is hard to use. > > 3. It would be possible to migrate from gtk3 to Xlib progressively since > Gdk3 with X11 backend translates to Xlib calls; > > 4. It would drop the gtk dependency (except for webkit-gtk). OS-specific > dialogs such as file save would be a problem (but not too hard to solve I > think). > > > References: > https://www.x.org/releases/current/doc/libX11/libX11/libX11.html > > https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/9 > https://discourse.gnome.org/t/custom-drawing-with-gtk4/7737 > > >
