Feature/wayland support

[pplupo]

1. Wayland Compatibility & Crash Fixes

• Removal of Legacy X11 Coupling: Cleaned up usages of QX11Info, GuiPrivate, and X11Extras throughout the codebase (spanning both desktop-apps and desktop-sdk). These legacy Qt5 dependencies were forcing X11 calls that caused immediate segmentation faults in pure Wayland environments. The application now fully relies on Qt 6's Platform Abstraction (QPA) layer, seamlessly supporting both X11 (xcb) and Wayland (wayland-egl) at runtime.

2. Chromium Embedded Framework (CEF) Stabilization

• API Hash Mismatch Fix: Reverted the CEF headers and wrapper sources in desktop-sdk to version 109. The codebase had previously pulled in CEF 120 files, but the underlying pre-compiled vcpkg binary remained at CEF 109. Aligning the headers with the binary resolves the silent startup segfaults caused by the API hash mismatch.
• Source Tree Cleanup: Removed untracked/incompatible CEF 120 files and reverted variables (like cef_download_interrupt_reason_t and int64_t) back to their CEF 109 compatible types to fix associated build compilation failures.

3. Build Environment & Submodule Synchronization

• Docker Bake Optimizations: Improved the Docker build configuration (build/docker-bake.hcl) by introducing the desktop-builder target and resolving conflicting export strategies to streamline CI/CD compilation.
• Submodule Pointers: Synchronized submodule pointers for core, desktop-apps, desktop-sdk, web-apps, and sdkjs to accurately reflect the coordinated changes required for the Qt 6 / Wayland port.

Depends on: Euro-Office/core#113 Euro-Office/desktop-apps#30 Euro-Office/desktop-sdk#9, Euro-Office/sdkjs#64

[pplupo]

@chrip let's do this one now?

[rikled]

Thanks for the PR! Your continued dedication to the project is truly outstanding.

Now that the Qt6 PR is in, we need to prep this one for review. Whenever you have a moment, could you:

• Rebase the branches onto the current main branch (maybe it makes sense to wait until this PR is merged first),
• Expand the PR description with a high-level summary of the changes (since it's a fairly large update).

This will make the review process much easier for the team. Thanks again!

[pplupo]

@rikled rebased and the description was updated. Lmk what else you need. :-)
Thank you!

[rikled]

We now distinguish between common and os specific. So desktop-common builds web-apps, sdkjs, core-wasm and desktop-js. build/windows and build/linux use the output of common to build os specific code.

[rikled]

Thanks for rebasing the main PR! I think the submodules weren't rebased though. Could you rebase those as well?

Regarding the PR description:

2. Chromium Embedded Framework (CEF) Stabilization
   API Hash Mismatch Fix: Reverted the CEF headers and wrapper sources in desktop-sdk to version 109. The codebase had previously pulled in CEF 120 files, but the underlying pre-compiled vcpkg binary remained at CEF 109. >Aligning the headers with the binary resolves the silent startup segfaults caused by the API hash mismatch.
   Source Tree Cleanup: Removed untracked/incompatible CEF 120 files and reverted variables (like cef_download_interrupt_reason_t and int64_t) back to their CEF 109 compatible types to fix associated build compilation failures.

As far as I know, this project has never actually used CEF 120. These changes were just made during the creation of the PR, right? Upgrading to CEF 120 is definitely something we should do, but I think that should be handled in a separate PR.

3. Build Environment & Submodule Synchronization
   Docker Bake Optimizations: Improved the Docker build configuration (build/docker-bake.hcl) by introducing the desktop-builder target and resolving conflicting export strategies to streamline CI/CD compilation.
   Submodule Pointers: Synchronized submodule pointers for core, desktop-apps, desktop-sdk, web-apps, and sdkjs to accurately reflect the coordinated changes required for the Qt 6 / Wayland port.

I think there's a misunderstanding here. During the initial PR review, we changed the build process (see my earlier comment) so that common files and OS-specific files are built separately. Because of that, this main PR shouldn't need to modify the build process at all. It should only update the submodule references.

Regarding the submodules themselves, as far as I can tell only desktop-sdk and desktop-apps contain relevant changes. Most of the changes in core have already been merged, except for the CEF-related changes. Since CEF is no longer pulled in through vcpkg, those entries shouldn't be added back to vcpkg.json/vcpkg.conf. Also, your web-apps PR doesn't appear to contain any changes.

[rikled]

Hi @pplupo,

Thanks again, You're incredibly fast! I have some more comments:

• The .docker/desktop-apps.bake.Dockerfile changes (stage rename, desktop-export) target the old build flow; these shouldn't be needed anymore.
• The database-format support (SQLite/DuckDB/Parquet/MDB filters, warnings, mdbtools-dev) is cool, but it's unrelated to Wayland and depends on enum values in core

desktop-sdk:

• windowless_rendering_enabled gets set twice in Init_CEF: once conditionally for Wayland, then unconditionally for all Linux. One of these is probably unintended
• imageUpdated/handleImageUpdated and m_lastDpr/m_bufferDirty/m_waylandTimer appear unused (leftovers?)

desktop-apps:

• The hardcoded /qt6/6.11.1/gcc_64 is no longer needed, since qt is installed via common.cmake
• The DBus find_package + definitions block appears twice.

Edit: There's one part that worries me a bit: https://github.com/Euro-Office/desktop-sdk/pull/9/changes#r3509757678

Edit 2: I tested this locally on Wayland and found that umlauts don't work (e.g. typing ä/ö/ü via dead keys produces nothing or the wrong character). Testing further, it looks like non-Latin input doesn't work in general.

[pplupo]

@rikled this was super hard. If I knew it was going to be this hard before I started idk if I would have.

Please, check. :-)

[rikled]

@rikled this was super hard. If I knew it was going to be this hard before I started idk if I would have.

Sorry to hear that. You definitely didn't pick an easy challenge, which makes it even more impressive that you managed to pull this off in such a short time. That's genuinely remarkable. Great work!

Please, check. :-)

I'll take a look at it today. I also need to test whether the Windows build still works. At first glance, though, it looks very promising again. :)

Thank you for your hard work!

[pplupo]

Your kind words are always encouraging. Thanks. :-)

[rikled]

I've looked over the code and don't see any major issues at first glance. There are a few minor things that I'll point out later.

I tested it locally in a Wayland session, and it works great. Then I switched to an X11 session, and unfortunately, it no longer works. I can take a look at it if you need a break. :)

In general I think we're almost there!

[pplupo]

@rikled to be honest, I actually ran into a bug myself when I was testing the db support, and it's due to wayland.
I'm at the moment trying to fix it. It's the clipboard, it's not integrating with the system's clipboard. I'm exploring a few alternatives to see if I can find a clean and elegant solution.

I'd appreciate very much if you could work on the x11 issue. It should work on both.

[pplupo]

@rikled I think I finally got the clipboard issue fixed.
I'm working on the db support now (other branch). I'd appreciate if you could take a look at the x11 thing.

[rikled]

@pplupo Thanks, that sounds great! I have a few other things I need to take care of right now, but I'll get to it soon.

[pplupo]

@rikled I finally fixed the scaling issue. It was a bit tough to fix because OnlyOffice was too large and I had to find something to use as reference for the baseline size. I ended up comparing buttons and canvas sizes with Libre Office to find a correction factor, so it's not too small on scale 1x and it grows proportionally according to the monitor scaling setting. It looks good to me now. Comfortable, I'd say. Check it out and lmk what you think. If you are ok with it, I'm ok too. Couldn't find any other issues.

@chrip FYI

[rikled]

That's great; I think we're almost ready to merge. I've fixed the X11 issues. Two things, though:

• It looks like you merged OnlyOffice 9.4.0 into the project (specifically the changes to the license). We can't do that right now, so those changes absolutely have to be removed first.
• Also, it looks like you’ve mixed in your configurable arch baseline PR here.

Once these two things are taken care of, I’d suggest that @chrip takes another look at it, and then we can merge.

[pplupo]

I have absolutely no idea how I did that. I'll correct it.

[pplupo]

OK, I figured it out. I accidentally merged my configurable-arch-baseline here. And I also accidentally branched configurable-arch-baseline from "master" instead of "main," and "master" has onlyoffice stuff.
Honestly, "master" should be renamed to "onlyoffice", because it's extremely confusing to have "master" and "main." My mistake is bound to happen again with other people.

[pplupo]

@rikled I'm cleaning things and still doing tests on x11 scaling.
I hope I'll be done with eveyrthing tomorrow. I'll let you know.
@chrip FYI

[pplupo]

ok, the scaling fixes are in! They were made in core and desktop-sdk.
I think it's all good now. Unless you find anything, I think this is done. I'm OK with merging.

It only took me an entire week. lol This was a tough one.

I felt the QT was there as a second thought, like a fallback. It didn't get as much love as GTK. The dialogs were poorer in formatting and overall design. After fixing the scaling, they looked horrible. I tried to reproduce the same look as the GTK dialogs so that users have a standardized (and more pleasant) experience.

@rikled
@chrip

[chrip]

Thanks @pplupo!
I tried to get the CI green. The PR's CI is red only because the fork can't run the secret-gated stages, so I ran it in-repo.
Linux amd64/arm64, crosscompile, and common all pass, but windows both fail at CMake configure: https://github.com/Euro-Office/DesktopEditors/actions/runs/30266743437

@rikled I have no idea what the current status of the Windows build is. Does it theoretically already work in the gh action?

---

This is what Claude suggests to fix the Windows build:

Root cause is in desktop-sdk → ChromiumBasedEditors/lib/CMakeLists.txt: two Linux-only CEF headers got added to the unconditional ASCDOCUMENTSCORE_HEADERS list —

include/internal/cef_linux.h        (line 497)
include/internal/cef_types_linux.h  (line 512)

On Windows CEF_SRC_PATH points at the windows CEF tree, which has neither, so target_sources (line 1103) fails: "Cannot find source file: …/cef_linux.h". They're already listed in the Linux else() branch (lines 1086–87), so just drop them from the common list and re-bump the submodule pointer — Linux is unaffected. Worth a full re-run afterward to confirm nothing else surfaces on Windows.

[pplupo]

I have no way to test this on Windows, folks. :-/
@chrip @rikled

Sry.

[rikled]

@pplupo @chrip Yes, the gh action should work. I'll take care of it. I had already removed those two lines, but they were probably merged back in:

include/internal/cef_linux.h        (line 497)
include/internal/cef_types_linux.h  (line 512)

Probably they just need to be removed again.

Thanks everyone!

[rikled]

@pplupo I tested on Linux X11 and Wayland which works great. On Windows however the editors no longer load. I will take care of that.

I need your help to get a better understanding of the situation:

• The desktop SDK PR includes the database changes again. Is there a reason why you added them back? If not, I'd still like to exclude them from the merge.
• This PR also points to a PR in web-apps, which, however, has nothing to do with Wayland support, right? So the submodule should point to the current main branch of web-apps.
• How does the PR in sdkjs fit into this PR? The description says that it fixes the mouse cursor issues. However, the code looks more like it fixes copy-paste issues. Also, this PR contains elements from your wavy line PR again. Could you update the description and remove the wavy line changes?
• Please make sure you properly sign off all your commits before the merge.

Thanks again! Unfortunately, the process is taking a little longer than expected, but it is, after all, a significant change to the code.

Edit: I fixed the windows issue but I cannot push to you desktop-sdk branch. Could you grant me rights?

[pplupo]

@rikled Thanks for the detailed review! Addressed all four points:

• desktop-sdk (database changes): rebased release/wayland-db-support to remove the parquet/BerkeleyDB commits and their wrapper merges — confirmed no database-related content remains in the diff. Force-pushed.
• web-apps: no Wayland-related content was actually left on that branch (it was just the wavy-underline feature), so the submodule now points straight at web-apps' main.
• sdkjs: rebased out the wavy-underline commits, force-pushed, and updated the PR OnlyOffice references everywhere #64 description to accurately cover the cursor fix, the native clipboard bridge fix, and the Colorpicker/device-scale fix.
• Sign-off: all commits across the branches are now signed off (including merge commits, which git merge doesn't sign by default).

Also invited you as a collaborator on pplupo/Euro-Office_desktop-sdk with write access so you can push directly — should be in your GitHub notifications.

Thanks for your patience on this one!

[rikled]

@pplupo Thanks a lot for the update and the permissions. I pushed the Windows fix. Unfortunately, there are still a few issues:

• The mouse cursor fix has caused the cursor to no longer change in either Windows or a Linux X11 session.
• The rescaling seems inconsistent, especially the top bar. In the Wayland session, it’s too large at a resolution of 2880x1800, and too small in the X11 session. The rescaling doesn’t seem to work properly in the spreadsheet editor. The cell labels are incorrect when switching between screens.
• Sometimes I get the following error when closing an editor (in wayland session):

QPainter::begin: A paint device can only be painted by one painter at a time.
QPainter::translate: Painter not active
QPainter::worldTransform: Painter not active
QWidgetEffectSourcePrivate::pixmap: Painter not active
QPainter::worldTransform: Painter not active
QPainter::setWorldTransform: Painter not active
QPainter::setWorldTransform: Painter not active
QPainter::begin: A paint device can only be painted by one painter at a time.
QPainter::translate: Painter not active
QPainter::worldTransform: Painter not active
QWidgetEffectSourcePrivate::pixmap: Painter not active
QPainter::worldTransform: Painter not active
QPainter::setWorldTransform: Painter not active
QPainter::setWorldTransform: Painter not active

Do you have the possibility to test within an X11 session?

Sorry that it's taking so long. Just to be clear again: you're doing an amazing job, and your contribution is really helping us move the project forward!

[pplupo]

OK, I'll take a look at these things soon. I'm working on something else on a different branch but I'm almost done.

I can test it using XWayland.

Sorry for the dumb question, what are the cell labels?

Can you post a screenshot of the title bars at that resolution and tell me your UI scaling factor?

[pplupo]

Thanks for the detailed report, and sorry it took a few rounds to actually land — the fixes were sitting in the submodules but the superproject's pointers here hadn't been bumped to include them until now, so nothing you tested could have shown them. That's fixed; this branch is now current.

Cursor no longer changing (Windows/X11): the title-button HoverLeave handler that resets the cursor was running on every platform and fighting whatever cursor the editor content had set — it's now Wayland-only. Separately, and more significantly: CCefView::OnCursorChange was unconditionally telling CEF "the app already set the cursor" on every platform, which suppressed CEF's own native cursor-setting in windowed mode (X11/xcb, Windows) — that handler exists for Wayland's off-screen-rendering mode, where CEF has no native window to set a cursor on itself, but it had no platform gate. That's now scoped to Wayland OSR only.

Rescaling inconsistency, especially the top bar: the app was multiplying its chrome sizes by a manually-detected DPI ratio and Qt was scaling the result again itself, so on a 1.25× display the chrome rendered at 1.5625× while the editor content (scaled once, via CEF page zoom) sat correctly at 1.25×. Worth flagging this wasn't Wayland-specific — Qt 6 scales on xcb too, so X11 had the identical compounding, just less visible since it erred in the same direction as Wayland. The manual factor is now a residual over whatever Qt already applies. Also fixed: the editor no longer visibly rescales twice on startup or when dragged across monitors with different scales — a debounce meant to guard against an initial compositor-timing race was instead delaying every legitimate scale change by two frames.

QPainter errors on close: QGraphicsDropShadowEffect renders through its own painter, and the Wayland compositor can trigger a concurrent repaint while that painter is open, mid-teardown. Wayland compositors draw window shadows natively anyway, so the Qt software shadow is now disabled there; X11 and Windows are unchanged.

I tested the scaling fix specifically at 1.25× and 1.5× across two monitors and confirmed the chrome and editor content now agree with each other and with X11 at the same configured scale. If your X11 session is still showing things too small, could you share the output of xrdb -query | grep -i dpi along with your display resolution and configured scale? I suspect Xft.dpi isn't set on that box, which would be a DPI-detection gap rather than the compounding issue above — happy to chase that down with that info.

[rikled]

Thanks, @pplupo. I think it looks really good now. I've tested it on X11, Wayland, and Windows. It runs like a charm. I fixed a small scaling issue in X11, lgtm now.

From now on, we should focus on fixing issues and not add anything new so we can get this merged. Some comments from my side:

• UpdateUIScalePercentage() doesn't compare against the previously applied factor, so the 1s poll timer does a full SetZoomLevel + WasResized() + per-frame ExecuteJavaScript every second even when nothing changed. Understood why the two-read debounce was removed, but an equality check on dFactor gets the same responsiveness for free. Also please drop the [UIScale] console.logs.
• _isNativeClipboardAvailable() keys off nativeClipboardWrite && cefQuery, and CClipboardQueryHandler isn't Wayland-gated, so Windows/X11 run the bridge and navigator.clipboard.write() against the same OS clipboard, last write wins. Gate on an explicit OSR flag. Also _nativeClipboardRead has no timeout despite the comment, and _dispatchPaste calls preventDefault() with no fallback to _private_onpaste, so an empty read is a silent no-op (try pasting a file from the file manager).
• device_scale.js disables correctApplicationScale on all desktop platforms, not just Wayland OSR, could be a problem once we have MacOS builds.
• The CDP bridge (SendGatewayDevToolsMessage) is unrelated to Wayland. Same for the restart rewrite, the int64→int64_t churn, and the icon/styling changes.

[pplupo]

I'll look into it.

[pplupo]

@rikled
Thanks for the review! I've addressed the first three points and will follow up shortly with details. On the fourth — I've searched the diff for SendGatewayDevToolsMessage/DevTools-gateway code, the restart rewrite, the int64→int64_t churn, and the icon/styling changes, and I'm not finding any of them in what's actually on this branch right now. Could you point me to the specific commit(s) or file(s) you're seeing these in? I want to make sure I'm cleaning up the right thing rather than removing something else by mistake.

[rikled]

Sorry for not being more precise before.

SendGatewayDevToolsMessage:

• https://github.com/Euro-Office/desktop-sdk/pull/10/changes#diff-78a9ee4b8a1018060d738d43ce343334febadd85c8f797860ea7697ed693915cR226-R227

int64_t e.g.:

• https://github.com/Euro-Office/desktop-sdk/pull/10/changes#diff-2d5bbff2086ea0b33e4abf1742726335a25ac4bedbdd1ad7132ae74b759cb379R267-R541

I thought again about restart rewrite and I think we can keep it. But for the records:

• https://github.com/Euro-Office/desktop-apps/pull/30/changes#diff-9e20bf2b913a327abb5a3cac50c90fa38ed1fd966260608271b64d56f2c27199R121-R126
• https://github.com/Euro-Office/desktop-apps/pull/30/changes#diff-9e20bf2b913a327abb5a3cac50c90fa38ed1fd966260608271b64d56f2c27199R153-R163

icons:

• https://github.com/Euro-Office/desktop-apps/pull/30/changes#diff-29a15cde71823a5306e2861a5b4b95f99273be080dc2e0518bb5cfe0660d441e
• https://github.com/Euro-Office/desktop-apps/pull/30/changes#diff-8de1606aa0150a3e2bbf603e6aad5534e6832debdca4d98dc5c72c045f5eabd7

[pplupo]

@rikled can you please take another look?

[rikled]

Thanks! I'm happy. @chrip Can you have another look?

[chrip]

LGTM on the substance. My earlier Windows CMake blocker is fixed (verified green on both
Windows arches in the in-repo run), and all of @rikled's 08-06 points hold up when checked
against the pinned code: the UI-scale dedup, the Wayland-gated clipboard bridge with its
timeout and paste fallback, the isWayland gate in device_scale.js, and the DevTools
bridge removal. Nice work @pplupo — and the code comments in this round are genuinely good.

Approving, as I trust @rikled to handle the submodule-pointer coordination at merge. Three
to-dos for the merge:

• web-apps: the pin (31217eed) is not on any Euro-Office ref and has no PR. Its only
  content delta vs main is apps/spreadsheeteditor/main/app/controller/DocumentHolder.js
  (+12/-1, the OSR context-menu fix — looks correct). Worth a small PR, then re-pin to main.
• Fresh CI on the final head: last green in-repo run was b10197ba8 (07-29); head is
  4b2fa25e5, 5 submodule bumps later. The PR's own red checks are just the fork-token
  artefact, not a build failure.
• Merge order: four pins are PR heads (core#113, desktop-apps#30, desktop-sdk#11,
  sdkjs#64 — note the body still lists the closed #9). Squash-merging any of them orphans
  the pin, so merge-commit them and re-bump the pointers here.

Non-blocking: the int64→int64_t churn is still in desktop-sdk (and now inconsistent — new
lines still use int64), and message_warn.svg's colour change is unrelated.

Assisted-by: ClaudeCode:claude-opus-5