Chapter 16

The desktop build

Everything so far was captured in a browser, because that is the build anyone can open without installing. The desktop builds — macOS, Windows, Linux — run the same Flutter code and look the same. The window below is the Linux build with the bundled demo, a key entered, and {{baseUrl}}/users answered in under half a second — nothing in the chapters before this one reads differently here.

Three things are genuinely different, and they are the reasons to install one.

The Linux build: same demo, same request, a real answer. — 1: Workspace — on the desktop, a folder you choose; 2: Command palette; 3: Send, and a square to stop it; 4: The cookie jar — it works here; 5: Settings, with a folder picker and updates — Figure 41: The Linux build: same demo, same request, a real answer.

16.1A workspace is a real folder

Figure 42: Settings on the desktop. Two things here do not exist in a browser.

Choose folder… points Baton at a directory, and that directory is the workspace: the YAML files are on disk where any editor, any script and git itself can reach them. A browser has no folder to point at, so it keeps a workspace in browser storage and reaches git through a host’s API or a worker.

The Updates section is the other one. A desktop build checks the site for a new version and installs it in place when you press Update the check carries no identifier and the toggle turns it off entirely. Store builds update through the store, and the browser build is simply whatever the site is serving.

16.2Cookies work

Figure 43: The jar on the desktop: empty, but real.

A response that sets a cookie lands here and is sent with later requests for the rest of the session — and nothing about it is written to the workspace or to run history, because a cookie is usually a session credential.

In a browser this dialog says instead that the build cannot use cookies at all. That is the platform’s rule, not Baton’s: a page may neither set a Cookie header nor read Set-Cookie, which is exactly what stops a web page forging another site’s session.

16.3Git without an intermediary

The desktop builds talk to git directly, so a commit is made and signed on your machine and the full history is local. Through a host’s API — the browser’s only option without a worker — the commit is created by the host, which means no local history and no commit signing. If signed commits matter, this is the build to use.

Note The screenshots in this chapter are the Linux build of 0.2.10, run on a virtual display. Their frames are measured, not drawn by eye — but not in the same place as the rest of the manual. The desktop build registers on the AT-SPI accessibility bus and then exposes no tree through it, so there is nothing to measure inside it. The frames therefore come from the browser build at the same window size, which runs the same Flutter code and puts the widgets on the same coordinates: Send, found in both screenshots by its colour rather than by eye, occupies the same rows and ends on the same column. What differs between the two is content — this build lists the demo’s requests in the order the demo declares them, the browser sorts them by name. Widgets that exist only on the desktop — the folder picker, the updates section — have no counterpart to measure, so those two figures carry no frames at all.

16.1A workspace is a real folder#

16.2Cookies work#

16.3Git without an intermediary#

16.1A workspace is a real folder

16.2Cookies work

16.3Git without an intermediary