What BlinkGTK Is For

Version: 1.2.0-build2 / 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 explains
which properties lead to which uses, working from features that actually exist.

Four properties that apply regardless of use

Before the use-by-use section, here is what applies across all of them. These four are
more useful for deciding "does this fit my case" than any list of markets.

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.

By use

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.

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 → 151. In Chromium 151, for instance,
emphasis marks no longer grow the line pitch when the leading has room.

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.