Repository navigation
"Positioning" does not work under pure Wayland #170
Description
After making things work on Linux aarch64 (#168) I can not run PDF-Over correctly in a KDE Wayland session.
When forcing Xwayland it works:
GDK_BACKEND=x11 java -cp './pdf-over-build/lib/*' at.asit.pdfover.gui.Main "$@"
However trying pure Wayland mode does not work:
GDK_BACKEND=wayland java -cp './pdf-over-build/lib/*' at.asit.pdfover.gui.Main "$@"
I did read your comment so it seems you are aware of that and set GDK_BACKEND to force Xwayland for now:
But I would be interested
- did you find out already what the exact problem is? Is it in your code? Or is it that a third party dependency you are using that takes care of that preview and positioning is broken?
Also, can we keep this issue open just to keep track of Wayland support?
Thanks!
Activity
mkurz commentedon Dec 11, 2025
Also, since Gnome already dropped the X11 backend, and KDE will do so as well in 2027 I hope this gets fixed. I know for many years we can still just force Xwayland, however even GTK will drop the x11 backend with gtk5, so the
GDK_BACKEND=x11workaround will stop working someday (still many years away however).mkurz commentedon Sep 1, 2026
Small clarification after digging into this further:
PDF-Over is already mostly capable of running as a native Wayland application. Its main UI uses SWT’s GTK backend, so when launched without forcing
GDK_BACKEND=x11, GTK can create the SWTShelldirectly on Wayland. This explains why most of the UI works and whyxeyesdoes not track the pointer over it.This does not mean that OpenJDK 21’s AWT supports Wayland. The problem is specifically the positioning view:
PositioningCompositecreates anSWT.EMBEDDEDcomposite and callsSWT_AWT.new_Frame(...).SignaturePanelis a SwingJPanel.SWT_AWT.new_Frame()usessun.awt.X11.XEmbeddedFrame, so this embedding path is inherently X11-based.A native Wayland SWT window therefore cannot host that X11 embedded frame in the same way. The underlying limitation is in the SWT/AWT bridge, but the actionable problem in PDF-Over is our use of that bridge - not PDFBox or the PDF renderer.
This also explains the launcher setting:
GTK tries those backends in order, so it chooses X11 whenever XWayland is available. That keeps SWT and AWT on the same X11 backend and makes positioning work, but prevents the application from using native Wayland.
I have a local local branch which replaces the embedded AWT/Swing preview with a pure SWT
Canvas. That removes the X11-specific bridge and should allow the complete UI, including positioning, to run natively on Wayland.mkurz commentedon Sep 1, 2026