Pascal Garber – Logbook

A new jumplink.eu, with a new look

2026-10-30T00:00:00Z

It was time for a redesign again. The old design had become too grey, too heavy on text and out of date:

The look

I did not want to give up the pixel-art look, but I wanted more colour and more life on the page. I live in Cuxhaven, so every page opens with the view from the dike: sky, sea and, on the horizon, the Kugelbake, the town's landmark beacon. If your system is set to dark mode it is evening, with moon and stars; otherwise it is day.

The scene moves. The waves roll, container ships, fishing cutters and gulls pass by during the day, shooting stars and aircraft at night. If you asked your system for less motion, you get a calm still picture instead.

On the home page I stand in front of the water myself, as a pixel figure. It was made with AI, but locally on my own computer: with ComfyUI, the FLUX.2 Klein 4B model and the pixel-art-sprite_limbicnation LoRA.

Everything else stays calm: text stands free on the background with hardly any boxes, set in Adwaita Sans, GNOME's typeface. The only pixel font left is the one for my name in the sky. A few words are borrowed from the RPGs I like: the CV lists quests and items, the skills form a small skill tree, and the blog is the Logbook.

By the way, a small hint: click the moon or the sun to switch between day and night. Maybe a few more little gimmicks will turn up over time. :)

The site sets no cookies, has no tracking and loads nothing from other servers. The old site is kept in the repository under the tag v2-riba.

Learn 6502 Assembly, a GNOME app

2026-10-29T00:00:00Z

The 6502 is the processor of the Commodore 64, the NES and the Apple II. Nick Morgan's easy6502 is a web tutorial that teaches its assembly language step by step. I turned it into a native GNOME app: Learn 6502 Assembly.

What is in it:

An interactive tutorial that walks through the core concepts.
A code editor with syntax highlighting.
An assembler and a debugger that show registers, flags and memory while the code runs.
A virtual display where you see the result, which is what makes small games and graphics possible.

It is written in TypeScript with GJS and libadwaita, and built with gjsify. The repository holds more than the desktop app: the assembler, simulator and disassembler live in their own package, @learn6502/core, and the same code also drives a web version and an Android app. The tutorial content and the translations are separate packages too, and translating happens on Weblate.

The app is on Flathub. The code is GPL-3.0; the tutorial text is CC BY 4.0, as in the original.

Why gjsify

2026-10-28T00:00:00Z

GNOME apps can be written in JavaScript. The runtime is GJS, powered by SpiderMonkey. But GJS is neither Node.js nor a browser: there is no node:fs, no fetch, no <canvas> and no npm ecosystem waiting for you. Many libraries, whether an HTTP client, a game engine or a crypto library, assume APIs that GJS does not have.

gjsify fills that gap. It reimplements the Node.js, web and DOM APIs on top of GNOME's own libraries:

You write	gjsify runs it on
`node:fs`, `node:net`, `node:crypto`	Gio, GLib
`fetch`, `WebSocket`, `XMLHttpRequest`	Soup 3
`<canvas>` 2D and WebGL	Cairo, Gtk.GLArea
WebRTC, WebAudio, `<video>`	GStreamer
`node:sqlite`	libsqlite3

This makes the standard APIs available in GJS. Libraries written for Node.js or the browser now run directly on GJS, with no browser engine and no Node.js runtime. There is no wrapper server, no bundled Chromium and no shelling out to Node. The result is a real GTK 4 and Adwaita app that you can ship as a Flatpak and that still speaks the language of the wider JavaScript world.

And the other way round

If you prefer Node.js or Bun, you can keep using them. For that I built the reverse direction too: the GJS APIs, meaning GTK, Adwaita and everything else GObject Introspection offers, are available under those runtimes as well. So every native API runs on every runtime.

And it behaves the same there. Tests make sure of that: the same tests check the Node.js APIs, the web APIs, the GObject Introspection APIs and the GJS runtime APIs on each runtime, and the result has to be exactly the same everywhere. That is why you can switch the runtime during development without touching the code.

It opens up other systems as well: with gjsify you can ship GJS apps for macOS and Windows, as an .app and .dmg, or as a program folder and .msi.

What I wanted from it

Native on GNOME first. GJS is the main target.
The ecosystem, unmodified. The test is whether npm packages run as they are. The Excalibur.js game engine, WebTorrent, socket.io, three.js, axios and the Anthropic MCP SDK all run on GJS through gjsify, checked against their own upstream tests.
One source, several runtimes. GJS, Node.js, Bun, the browser and NativeScript. Each package says which of them it reaches, and the build picks the right implementation.
No Node.js required. Install, build, run, test, publish and the Flatpak step all run on GJS itself.

Why I build my apps this way

I know TypeScript, the web and its tooling well, and I want to write GNOME apps without leaving that. ts-for-gir gives me types for GTK and every other introspected library, gjsify gives me the APIs and the toolchain. My own apps, such as Beifahrer, Steuererklärung and Learn 6502 Assembly, are the first test: if something is missing, I fix it in gjsify instead of working around it in the app.

The code is on GitHub, the documentation at gjsify.org.