Author: Jonah Graham

Kichwa Coders
Posted on

Easily running SWT on different Linux Distros

As a follow-up to my earlier article on testing and developing SWT on GTK, I’ve recently run into a set of challenges that require running SWT tests, samples, and even the full IDE across multiple Linux distributions and different GTK minor versions.

Historically, whenever I needed to test Eclipse on another distro, I’d either dual-boot my machine-using a shared data partition to keep setup simple, or, for quick one-off experiments, spin up a VM. Occasionally I’d throw together a Docker image just for a single test run.

But as I found myself switching between environments more frequently, those ad-hoc approaches grew cumbersome. I needed something faster and more repeatable. So I formalized the Docker approach and built a workflow that lets me launch Java applications-including SWT under X11 or Wayland-with just a click or two.

The result is swt-dev-linux (https://github.com/jonahgraham/swt-dev-linux), a GitHub repository where I’m collecting and documenting the scripts that make this workflow straightforward and reliable. If you need to test SWT across different Linux/GTK configurations, I hope it makes your life easier too.

Demo

Here is a screenshot where I have the SWT ControlExample running on 4 different distros simultaneously. It makes it easy to compare and contrast behaviours:

In a process tree this looks like:

The above examples were all running on GTK4 + x11, the next example is running GTK4 one on x11 and one on wayland on Fedora 43, with my host distro being Ubuntu 25.10:

Recursive SDKs Demo

Here is another screenshot showing (from top left):

  • Eclipse SDK setup with my main SWT development environment, launching:
  • a child Eclipse SDK running on my Ubuntu docker container, launching:
  • a child Eclipse SDK also running on my Ubuntu docker container, launching:
  • a hello world Java application

Here is what the process tree looks like for the nested SDKs:

Intrigued?

Come visit my GitHub repo at https://github.com/jonahgraham/swt-dev-linux and try it out and let me know what you think. File an issue or a PR!

Posted on

Testing and developing SWT on GTK

I have recently started working on improved support of GTK4 in SWT and I have been trying to untangle the various options that affect SWT + GTK and how everything goes together.

Environment Variables

These are key environment variables that control where and how SWT draws in GTK land.

  • SWT_GTK4: If this is set to 1 then SWT will attempt to use GTK4 libraries
  • GDK_BACKEND: Which backend the GDK layer (a layer below GTK) uses to draw. Can be set to x11 or wayland.
  • DISPLAY: when GDK_BACKEND is x11, controls which display the program is drawn on.

If SWT_GTK4 or GDK_BACKEND is set to a value that is not supported, then generally the code gracefully falls back to the other value. For example, setting SWT_GTK4=1 without GTK4 libraries will attempt to load GTK3 libraries.

If DISPLAY is set to an invalid value, you will generally get a org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed] exception (although there are other reasons you can get that exception).

GDK_BACKEND is often set by unexpected places. For example on my machine I often find GDK_BACKEND set to x11, even though I have not requested that. Other places, such as VSCode may force setting GDK_BACKEND depending on different circumstances. Therefore I recommend being explicit/careful with GDK_BACKEND to ensure that SWT is using the backend you expect.

X11 and Wayland

When Wayland is in use, and GDK_BACKEND=x11, then Xwayland is used to bridge the gap between an application written to use X11 and the user’s display. Sometimes the behaviour of Xwayland and its interactions can differ from using a machine with X as the real display. To test this you may want to install a machine (or VM) with a distro that uses X11 natively, such as Xubuntu. The alternative is to use a VNC server (see below section).

X11 VNC Server

Rather than installing a VM or otherwise setting up a different machine you can use a VNC Server running an X server. This has the added benefit of giving a mostly accurate X11 experience, but also benefits from maintaining its own focus and drawing, allowing X11 tests to run without interrupting your development environment.

In the past I have recommended using Xvfb as documented in CDT’s testing manual. However, for my current SWT development I have used tiger VNC so I can see and interact with the window under test.

When I was experimenting on setting this up I seemed to have accidentally changed my Ubuntu theme. I was doing a bunch of experimenting, so I’m not sure what exactly I did. I have included the steps I believe are necessary below, but I may have edited out an important step – if so, please comment below and I can update the document.

These are the steps to setup and configure tiger vnc that worked for me on my Ubuntu 25.04 machine:

  • sudo apt install tigervnc-standalone-server tigervnc-common Install the VNC tools
  • sudo apt install xfce4 xfce4-goodies Install an X11 based window manager and basic tools (there are probably some more minimal sets of things that could be installed here)
  • vncpasswd Configure VNC with a password access control
  • sudo vi /etc/X11/Xtigervnc-session Edit how X11 session is started. I found that the default didn’t work well, probably because xfce4 was not the only thing installed on my machine and the Xsession script didn’t quite know what to do. The exec /etc/X11/Xsession "$@" didn’t launch successfully, so I replaced that line with these lines:
    unset SESSION_MANAGER
    unset DBUS_SESSION_BUS_ADDRESS
    exec startxfce4
    The SESSION_MANAGER and DBUS_SESSION_BUS_ADDRESS are unset because I wanted to keep this session independent of other things running on my machine and I was getting errors without them unset.
  • vncserver :99 Start the VNC Server – adjust :99 for the display you want to use, you set DISPLAY environment variable to :99 in this case.
  • xtigervncviewer -SecurityTypes VncAuth -passwd /tmp/pathhere/passwd :99 Start the viewer, use the command that vncserver output as part of its startup

Wayland Remote connection

I have not had the opportunity to use this much yet, but recent Ubuntu machines come with desktop sharing using RDP based on gnome-remote-desktop. This should allow connecting to a Ubuntu machine and use Wayland remotely. Enable it from Settings -> System -> Remote Desktop and connect to the machine using Remote Desktop.

What to test?

Now that I am developing SWT, specifically targetting GTK4 work, there are different configurations of the above to test. My primary focus is to test:

  • SWT_GTK4=0 with GDK_BACKEND=x11 running on the default DISPLAY that is connected to Xwayland
  • SWT_GTK4=1 with GDK_BACKEND=wayland (in this case DISPLAY is unused)

However these additional settings seem useful to test, especially as x11 backend sometimes seems to be used unexpectedly on wayland:

  • SWT_GTK4=0 with GDK_BACKEND=x11 running on the DISPLAY connected to my VNC. This is really useful for when I want to leave tests running in the background
  • SWT_GTK4=1 with GDK_BACKEND=x11 the behaviour of various things (such as the Clipboard) is different when using GTK4 with wayland. I don’t know how important this use case is long term
  • SWT_GTK4=0 with GDK_BACKEND=wayland – I don’t know if this really adds anything and have hardly tried this combination.

Run Configurations

Here is what a few of my run configurations look like

Posted on

Eclipse CDT 12 New Features – Eclipse IDE 2025-03

I am delighted to announce the release of Eclipse CDT 12 and CDT LSP 3, which will be generally available this Wednesday as part of the Eclipse IDE 2025-03 release.

The preferred way to get CDT is to install Eclipse CDT as part of the Eclipse IDE for C/C++ Developers using the installer. Further release information on how to get CDT will be published on Wednesday on the GitHub CDT 12 release page.

The two themes for the CDT 12 release are highlighting the new C/C++ editing experience based on the CDT LSP project by leveraging clangd and improved CMake integration, especially for CDT extenders. But there are many other new and noteworthy items, along with over 200 issues and PRs closed across CDT and CDT LSP repos.

Here is a video highlight of the new C/C++ Editing Experience based on the Language Server Protocol (LSP) using clangd and showing the improved CMake integration.

Posted on

EclispeCon talk: The reality of CDT’s LSP and Tooling situation

I will be delivering a couple of talks at EclipseCon 2024, recently rebranded as OCX – https://www.ocxconf.org/. Here is the abstract for the first of these (link to the slot in the program):

In this talk, we explain the current state of the C/C++ Development Tooling (CDT) and its future alongside Language Server Protocol (LSP) and its associated tooling such as clangd. As software development evolves, the integration of LSP has become pivotal in enhancing code editing experiences across various integrated development environments (IDEs). We will explore the successes and challenges faced in implementing LSP in CDT building on top of the Eclipse LSP4E framework, examining how it impacts productivity, code quality, and developer experience. The talk will also address the compatibility and performance issues encountered and future directions for improving CDT’s tooling. Attendees will gain insights into the practical realities of maintaining and evolving tooling for C/C++ development in a rapidly changing technological landscape.

Posted on

Wasm Diaries: Making My First Contribution to Emscripten

The Open-Source project: Emscripten

I have been working on a WebAssembly project porting some desktop code to run in a web browser and we have been using Emscripten as our tool chain. Emscripten is an open-source compiler toolchain that allows you to compile C/C++ code to WebAssembly, enabling it to run in web browsers. But it is more than a just compiler, Emscripten is a full SDK as it also includes the runtime library allowing interaction with the web browser with JavaScript.

The bug, a race condition?

My system has an Emscripten compiled C program running in a Web Worker that writes data that is read by another Web Worker. A SharedArrayBuffer is used to connect the two Web Workers together, basically as a queue. When the queue was big enough the program behaved exactly as expected, however when the queue filled up I would observe out of order and corrupt data on the read side.

For a simple example, if the C program did fprintf(f, "abcdefghijklmnopqrstuvwxyz\n“) the receiving Web Worker would receive a random character replaced with a newline, such as “abcdefg\nijklmnopqrstuvwxyz\n". I eventually determined that the corruption only occurred if the queue went from full to not full in the middle of processing a single write.

Determining this was difficult because any debugging I did or logging I added to my program changed the behaviour sufficiently to remove or at least significantly relocate when I saw the bug. This is why I concluded that it was a race condition.

Understanding the problem was related to the queue being full allowed me to configure my test case with a full buffer that I could control when it transitioned from full to not full (by careful placement of breakpoint on the receiving side) allowing me to step through a reproducible test case.

Once I was able to step through the code finding the bug was very easy, a simple loop termination condition was missing in the implementation of the doWritev function that underpins much of the stdio output handling.

Submitting my first issue

The first step in contributing anything non-trivial to an open-source project is to create a bug report. This allows you to discuss with the maintainers and the rest of the project’s ecosystem about the validity of your findings.

I summarized all my findings, along with my probable fix as a bug report in Emscripten’s GitHub issue tracker, Issue #22258.

The Emscripten maintainers were very responsive to my bug report which allowed me to have confidence that my assessment was probably correct, and that the community would be receptive to me doing the work to submit a Pull Request to resolve the issue.

Creating a Pull Request – have a good test case!

I could have created a PR with the one-line fix and called it a day as I already had a fix applied in my code base. The problem was possibly well enough understood to be merged with only that. However, to demonstrate exactly what the fix meant and to ensure it did not regress in the future writing a new test case was something I felt was important.

I had a working test as part of the test suite of my internal work, but it relied on my components that were not suitable to contribute to Emscripten at this time. My tests also relied on running the test in a tight loop to increase the chances of hitting the race condition. Therefore, I needed a more suitable test case.

Emscripten has an extensive test suite. The first step was to make sure I could run some tests and find a similar test I could copy as a starting point. Running some tests was straightforward with the test/runner program. To identify a test that may cover the same code I ran git blame on doWritev and identified a recent fix with associated test case that I used as my basis for my test, test_fs_writev.

I was able to write a simple test case that demonstrated the problem. The process of writing the test case also allowed me to understand the problem better, as well as learn a lot about the Emscripten code base. I captured my better understanding of the original problem in a new comment on my issue, and I submitted a Pull Request with my fix and test case, PR #22261.

The Review Process

Submitting the pull request was just the beginning. The next step was the review process. Emscripten maintainers reviewed my changes, provided feedback, and suggested improvements. This process was incredibly valuable as it helped me learn more and gave me the opportunity to dive into other related parts of the code base, such as the new WasmFS component to verify it didn’t suffer from the same issue. I was also able to submit a few additional smaller issues and PRs that were triggered by working on this bug fix.

After addressing the feedback, my pull request was merged into main. From observing the bug in my project to getting the PR merged was approximately one week and I am pleased that my bug fix will be part of an upcoming release of Emscripten.

Encouragement for New Contributors

I have been an open-source maintainer for many years, including being a project lead on various Eclipse open-source projects. This was my first contribution in a while on a project I had no prior relationship with. It was really useful to be in the position of a new contributor again as I plan to adapt some of my experiences to improving the other open-source projects that I am part of.

If you’re considering contributing to open-source projects, I highly encourage you to take the plunge. The Emscripten is a healthy project with attentive maintainers who engage well with potential contributors. I hope I can help provide contributors to Eclipse projects have the same sense of pride at contributing as I got from being a first-time contributor to Emscripten.