What BlinkGTK Is For

Version: 1.2.2-build6 / Language: English | 日本語

BlinkGTK is a component for building screens with web technology. Screens written in
HTML, CSS and JavaScript are embedded in, and run inside, a Linux application.

The screenshots we publish are of an e-book reader, which may make this look like a
library for reading Japanese books. That is one use. This document looks at
the uses first, then closes with the properties that do the work across
all of them — grounded in features that actually exist.

By use

On-device AI and web inference

AI is no longer a research topic. Document summarisation and translation,
meeting transcription, OCR for scanned paperwork, inspection-image
classification, conversational guidance at service counters — it is
becoming standard equipment in everyday software. And much of it is also
published in a form that runs inside a browser: web inference built on
WebAssembly and WebGPU, with a growing ecosystem of in-browser runtimes such
as Transformers.js and ONNX Runtime Web.

BlinkGTK brings that same foundation into a desktop application as a
single GTK widget. Which means this: entering the AI field does not
require building a machine-learning stack from scratch. You can start by
running, inside your own application, what already runs on the web.

Imagine the screens you could build:

A reading app with summarisation, translation and semantic search:
summarise the open document on the spot; translate as you read; find
"where was that discussed?" by meaning — with every document staying
local, not a single line sent outside
A meeting terminal whose minutes write themselves: speech recognition
for the transcript, extraction for the key points, speech synthesis to
read them back — without the recording ever leaving the device
A reception desk that turns paper into records: OCR scanned or
photographed forms and sort the fields. Paper that carries personal
information is exactly where on-device processing earns its keep
Measurement equipment that classifies inspection images in place: the
"never leaves the device" requirement from the medical section and an
image-classification model can share one screen
A guidance kiosk you can talk to: layer a conversational model onto
the signage configuration — a closed terminal that answers only from its
own body of knowledge

The common strength is a single one: serve the model from inside the
machine over a custom URL scheme, and the inference inputs never leave the
device. The stronger the privacy or confidentiality barrier in a field,
the more on-device AI is worth there.

The first steps are concrete, too:

Open an inference demo or library that runs in a browser — in BlinkGTK
(start from "what runs on the web, runs here")
Once it works, switch the model's origin to on-device delivery over a
custom URL scheme
Keep the screen and the inference in JavaScript; write only the hardware
and business-system glue on the C side (signals and script injection)

GPU-backed inference (WebGPU) depends on the hardware and driver
combination; as with the automotive section, verify on the real device.
This project itself is researching whether Japanese page layout can be
accelerated with WebGPU — experiment reports from the similarly curious are
welcome.

Wayfinding, signage, ticketing terminals

On a device the public touches, the requirement is that the screen does not leave the
state you intended. Close operations off with BLINK_CONTENT_POLICY_KIOSK, take the
screen fullscreen, and serve on-device content through a custom scheme — the pieces map
directly.

Authoring the display in HTML also helps upkeep: changing what is shown is a content
swap, not an application rebuild.

Game hardware, photo-sticker booths, entertainment terminals

Rich, continuously moving screens in an embedded device — the requirements of
entertainment hardware are one of the shapes BlinkGTK is best at.

Build the spectacle with web technology: Canvas, WebGL, CSS animation
and video playback are all in the box. Game menus, stores, rankings, event
screens, and a cabinet's attract loop — the "layer that draws people in" —
can run on web technology, separate from the game engine itself
Staying in motion is a release check: continuous frame delivery for
moving pages (Canvas animation, video) is verified on every release. The
class of regression where "optimising for quiet screens freezes moving
ones" is stopped by machinery — in entertainment, a frozen screen reads
as a broken machine
Seasonal events are a content swap: updating the show means replacing
HTML, not rebuilding the application. Limited-time decorations and event
screens rotate without touching the cabinet's software
For make-it-on-the-spot machines like photo-sticker booths: doodling,
stamps and frame compositing are exactly what Canvas is good at. Camera
and printer control live on the C side; the screen and the show live on
the web side — a split the JS↔︎C bridge is built for
Build the non-drawing parts in one unbroken line: make the screen web
technology, and everything around it that is not rendering — membership
and billing, campaign delivery, remote management servers, analytics on
the data you collect — shares the same technology, the same people and
the same assets. The web team that already runs your services can carry
the cabinet's screen too, with no separate stack raised just for the
terminal
Self-contained in a closed cabinet: serve content from inside the
machine over a custom URL scheme and the show works with no network at
the venue. Full-screen ownership and operation limits (content policy)
complete the closed, commercial-duty configuration

With both GPU (EGL) and software rendering available, you can match the
cabinet's GPU configuration. As everywhere else, verify on the real
device — rendering performance depends on the hardware and the screen
design.

In-vehicle screens must keep working when connectivity drops. Serving from the device
through a custom scheme means display still succeeds out of coverage. Scale control suits
switching between at-distance legibility while moving and close-up operation when parked.

Both GPU and software rendering paths exist, which leaves room to run on automotive SoCs
with constrained GPU configurations. Verification on the actual hardware is essential
— the rendering path depends on the hardware and compositor combination.

IoT / WoT control screens

Authoring a device's control panel in HTML means the same screen can serve both on the
device and in a browser at hand. BlinkGTK covers the on-device side.

There is a path from JavaScript into your C code (blink_web_view_execute_javascript()
and script injection), so the web screen can be wired to hardware control.

Medical and measurement equipment

To be clear first: BlinkGTK cannot warrant conformance as a medical device.
Regulatory compliance belongs to whoever builds the equipment. What follows is only
which features answer requirements commonly seen in that field.

Common requirement	Feature
Never reach an external network	On-device delivery via custom scheme
Restrict operations (guard against mistakes)	Per-operation content policy
Record what was displayed	`blink_web_view_capture_screenshot()`
Reproducibility of the display	Version obtainable at runtime and recordable

For visualising measurement data or GUIs for research instruments — outside regulatory
scope, where the need is simply "render graphs and tables well" — it is straightforward.

Publishing and Japanese typography

This is where we have the most experience today. Vertical writing, ruby, emphasis marks,
combined upright text and line-breaking rules are handled by Chromium's rendering engine
as-is.

What works and what does not is documented version by version, with measurements, in
Chromium 147 → 152. In Chromium 151, for instance,
emphasis marks no longer grow the line pitch when the leading has room.
In the current Chromium 153, placing a ruby annotation without inflating the
line height is on by default, and ruby placement itself has been rebuilt
(it does not apply in multi-column vertical writing — see the link above).

Six properties that apply regardless of use

Here is what has been doing the work across all the uses above. Even for a use
we did not list, these six properties are how to judge whether BlinkGTK fits.

1. It works without a network

blink_web_view_register_custom_scheme() registers your own URL scheme. A URL like
myapp://screen/main is handed to a function in your application, which returns the
content — so content already on the device is served directly.

No web server, no outbound connection. This matters for devices on closed networks, for
equipment operating out of radio coverage, and for environments where connectivity is
not permitted.

2. You can narrow what users are able to do

blink_web_view_set_content_policy() disables individual operations on the page.

Constant	Disables
`BLINK_CONTENT_POLICY_NO_COPY`	Copying to the clipboard
`BLINK_CONTENT_POLICY_NO_SAVE`	Saving the page
`BLINK_CONTENT_POLICY_NO_PRINT`	Printing
`BLINK_CONTENT_POLICY_NO_CONTEXT_MENU`	The context menu
`BLINK_CONTENT_POLICY_NO_DEVTOOLS`	Developer tools
`BLINK_CONTENT_POLICY_NO_SELECTION`	Text selection
`BLINK_CONTENT_POLICY_NO_SCREENSHOT`	Screen capture
`BLINK_CONTENT_POLICY_NO_DRAG`	Extraction by dragging

BLINK_CONTENT_POLICY_KIOSK applies them together. It answers the problem of
"browser features" surfacing on a device the general public touches.

blink_web_view_set_javascript_dialog_handler() lets the application intercept and
replace alert() and confirm() raised by the page — so an unattended device does not
stall behind a dialog nobody can dismiss.

3. It can own the screen, and adapt to viewing distance

blink_web_view_set_fullscreen_handler() and blink_web_view_is_fullscreen() control
fullscreen presentation. blink_web_view_set_zoom_level() changes the display scale, so
the same content can serve both a screen read from a distance and one operated by hand.

4. Use it from the language you already use

The C API is exposed as GObject, and GObject Introspection typelibs (.gir / .typelib)
ship with the distribution. Python (PyGObject), Rust, C++, JavaScript (GJS), Vala and
Go can call the same API with no extra binding layer.

5. It connects to external hardware

Between the screen (JavaScript) and the application (C and friends) runs a
two-way bridge — messages from JavaScript to C
(app integration API), script
execution and injection from C to JavaScript. Which means: any device you
can reach from C, the screen can use. Printers, cameras, sensors, IC-card
readers, payment terminals, serial devices — what you attach around the
terminal is your application's choice.

6. The web's evolution flows straight in

BlinkGTK tracks upstream Chromium (currently 153.0.8010.36). New CSS,
WebAssembly, WebGPU — the web platform's evolution arrives with version
updates, without swapping engines. What became possible in which version is
recorded, with measurements, in the
Chromium feature history.

First public appearance

BlinkGTK was first shown publicly at Interop Tokyo 2026 (Makuhari Messe).

Tell us your use

The above explains "these features exist, so these uses should fit" — it is
not a list of deployments. If you have built something with BlinkGTK, please send
screenshots to the
call for submissions.
What belongs here is what is actually running, not what we imagine.

For extensions targeting a specific environment — support for unusual
hardware, built-to-order features, or an accompanied proof of concept — we
take on custom development at blinkgtk.com. If the
standard distribution does not reach your requirement, start with a
conversation.