Repository navigation
fe: dress ubuntu, kubuntu, mint and omarchy in their own colours, every linux wore the same theme - #267
Open
landsman wants to merge 13 commits into
Open
fe: dress ubuntu, kubuntu, mint and omarchy in their own colours, every linux wore the same theme#267landsman wants to merge 13 commits into
landsman wants to merge 13 commits into
Conversation
landsman
changed the title
Owner
Author
|
To check on a real Omarchy machine. Everything so far ran on macOS, in Chromium, with the Omarchy colours pasted into the page by hand, so the whole path from file to page has never run in WebKitGTK. Detection
Colours (
Light and dark
Themes
Decide after seeing it
Not for Omarchy, but open here: Ubuntu, Kubuntu and Mint have not run on a real machine either, and no source shows what Kubuntu's |
…tlived the bump .cache/adminer-src.zip carried no version, so make saw the file, called it up to date and never fetched again. Bumping ADMINER_VERSION then failed in the extract -- "cannot stat .cache/src-tmp/adminer-6.1.1" -- on every machine that had built once before the bump, with nothing to do but work out that the cache was the problem and delete it. A bump now names a file that is not there yet, and the zips of versions we have left behind go with it.
…un months ago webview is cgo and asks pkg-config for webkit2gtk-4.0, which no current distro ships -- Ubuntu dropped it in 24.04, Arch never had it, and both carry 4.1, the same API over libsoup3 and what download_linux.go already names. The shim that bridges that went into /usr with sudo tee from linux-deps, which made `go build` on a working checkout depend on a command someone had run once, by hand, on that machine: a checkout where it had not run failed with "Package webkit2gtk-4.0 was not found", pointing at a search path rather than at the step that fills it. It is a build artifact like any other now, written to .cache and reached through PKG_CONFIG_PATH, exported because every go command here compiles the cgo launcher and not only the one that links it. That also leaves nothing distro-specific but the headers themselves, so linux-deps asks whether they are installed before it asks which package manager is present: Arch and Fedora were turned away up front, and one of them is where this was found. Where apt is missing it now names what to install and stops.
…sole there The whole of "debug the running app, do not guess" was a macOS instruction: enableInspector was real only there, and the !darwin stub returned false, so -debug on Linux printed "web inspector unavailable" and left nothing to debug with -- no console, no DOM, no breakpoints, on the platform where the app has no menu bar to offer them from either. WebKitGTK has an inspector of its own; it only needed developer extras turned on and a show(), from an idle callback because neither the main loop nor the window exists yet at that point. Closing its window only closes it -- WebKit keeps the inspector alive and show() brings it back -- but with no Develop menu there was no way to ask again, so F12 and Ctrl+Shift+I reopen it, taken on the GtkWindow where GTK offers a key press before the focused widget sees it, so it works with the caret in an SQL textarea. Console messages go to stdout as well, and so to the log: that is what is left when the page dies before the inspector is up. The hint in the log is per-platform now rather than naming Safari everywhere, and the two diagnostics split the same way -- a real describeUIDelegate on Linux answers the question worth asking there (is the window's child the WebKitWebView every install* hangs off), the Windows stubs moving to inspector_other.go.
…den the whole run The window is hidden on purpose until the loader has painted, and the only thing that brought it back was loaderShown -- a call from the page over a JavaScript binding. That binding is not guaranteed: on WebKitGTK 2.54 nothing from the page reaches Go at all, so every run of `make run` on Arch opened no window ever, while the server came up, served the page and logged a clean startup behind it. Nothing in the log said what was wrong, because by every measure Go could take the app had started. A reveal that can fail is not a reveal, so there is a deadline under it now: two seconds, well past the loader's own paint anywhere it works (759ms at its worst here, cold), and sync.Once so the good path still wins and this only ever fires where that path is broken -- where it also says so, since a hidden window is the symptom of a dead binding and that is worth naming rather than quietly papering over.
…e on linux An orphan was recognised by ppid 1, which is true on macOS and never true on Linux: systemd --user marks itself a child subreaper, so a server whose launcher was killed is reparented to that instead. So `make kill-orphans` and the SessionEnd hook that calls it after every agent session both printed "no orphaned frankenphp server" while fourteen of them held fourteen ports on this machine -- the exact failure the script exists to prevent, reported as success. The reaper set is init plus any systemd --user now, and the test covers a Linux reparent beside the macOS one.
…ARY empty on linux The dresscode PostToolUse hook started dresscode through PHP_BINARY, which the mac frankenphp fills in and the linux one leaves as "". proc_open refuses an empty program name, so every PHP file an agent wrote on Linux ended in an uncaught ValueError: the file was never checked, and the agent was told nothing -- the convention this hook exists to enforce was simply not enforced there. bin/frankenphp beside the root is the same binary, and asking the filesystem rather than the string also keeps phpstan from calling the check dead code, its stub having PHP_BINARY as non-empty.
…omarchy theme check.sh posts a light and a dark design and expects both back gated on prefers-color-scheme, which is how the OS theme picks one. On Omarchy that cannot hold: LinuxDistro finds ~/.local/state/omarchy, Auto then follows that machine's current theme rather than the system, and a theme with mode = "dark" pins the page to one side, so only the dark design comes back and the assertion fails. Nothing was broken -- the check was reading the desktop it ran on. That is the dearest shape a failing test has. It stays green in CI and on macOS, where no such theme exists, and on main, which has no Omarchy code: red for one developer and green everywhere else reads as a regression in whatever that person last touched, and costs an investigation to find out it is not one. HOME into the throwaway data dir the script already makes and removes gives every machine the answer CI gets, on every platform, and leaves the assertion measuring what it is for -- that switching design works before login. The seam is the one tests/cli/OmarchyThemeTest.php already uses, and that test covers the Omarchy reading deterministically, so nothing is lost by keeping it out of here. The e2e fixture inherits this process's environment and boots the same app for scenarios that assert the theme light and dark, so it takes the same line.
…ody picked The dialog's Save is filled in --ad-ok, and an Omarchy palette replaces that token with the theme's own `green`. A terminal palette's green is chosen to be read as text against the background, not to be a surface: Tokyo Night's #9ece6a arrives as a lime slab under dark text, which is the one loud thing on an otherwise quiet window, and every theme whose green is a terminal green does the same to it. So Save wears what .message already wears on this side, the same two tokens the rest of the page pairs: the green as text over --ad-ok-bg. It stays the filled one of the two buttons, Reset being text and a border over nothing, so the pair still reads at a glance -- which is the whole reason Save is green and not the accent. Measured over the 23 themes installed here rather than judged on one: the theme's green on --ad-ok-bg clears 4.5:1 on 19 of them (8.4:1 on Tokyo Night), against 16 for a tint mixed from the theme's own background, which was the other candidate. The four it does not clear are themes with a muted green -- miasma, retro-82 and two light ones -- and .message has that same contrast there today, so it is one fix for both and not this one.
… at a running daemon `make debug` brings the e2e's mysql up so there is something to log into, and when it cannot it said "no mysql: docker is not running" -- the one explanation the Makefile had for every way docker can be unusable. On a machine where the daemon is up but the user is not in the docker group, that sends you to systemctl to look at a service that is already active, and the socket is nowhere in the sentence. Found by being that machine. The reason is docker's own now, because it already distinguishes the cases precisely, and a permission denied also gets the fix for it: the group to join, and that a login is what makes it take. The Makefile stops explaining a failure it cannot see the cause of.
…h hard corners
Omarchy's own default is rounding = 0 (default/hypr/looknfeel.lua) and a theme does not
touch it -- a theme ships colours, and only the user's own hypr config overrides the
rounding -- so the desktop around this window has hard corners while the app put a 7px
radius on every panel, input and button in the middle of it, which is the look of a web
page in a window rather than of a program on that desktop.
The two radius tokens carry most of it. The rest is a short list of corners that do not
come through them, found by grep and minus the two sets that cannot show here: window.css
is the macOS frameless chrome, and a gallery design never has this sheet loaded over it.
A list rather than a blanket * { border-radius: 0 }, which would put a declaration on
every cell of a table that can run to thousands. Discs stay discs -- the connection icon
and the environment dot are shapes, not corners.
Read it from the desktop rather than hardcode it? Only the user's hypr config knows, not
the theme, and it is Lua: the rounding is commented out in mine, which a reader would have
to not mistake for a value. Not worth it to track a number that is 0 by default.
…nly for the console -debug turned the inspector on and opened it in the same breath, so every run it is good for -- dressing the window as another OS, reading the console in the log, clicking the app by hand -- began with an inspector window beside the app, to be closed before anything could be seen. macOS has never done that: setInspectable puts the page in Safari's Develop menu and opening it is yours. So Linux does the same now. F12 and Ctrl+Shift+I were already the way back after a close; they are the way in as well, which costs the one keystroke a Develop menu would have cost anyway. Console messages still reach the log whether it is open or not, which is the half of -debug that has to work without being asked for.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every Linux wore the same theme, in colours no Linux desktop uses.
LinuxDistronow tells Ubuntu, Kubuntu, Linux Mint and Omarchy apart, and each can have a stylesheet thatTheme::cssMap()loads as soon as the file exists. Ubuntu, Kubuntu and Mint get one here, with colours read from Yaru, Breeze and Mint-Y's sources and no code copied from them. Omarchy's colours come from its current theme instead, read at each page load, and Auto follows that theme's scheme.The distribution alone cannot decide this, because a look belongs to the desktop, so detection reads
os-releaseandXDG_CURRENT_DESKTOPtogether. KDE on another distribution and GNOME outside Ubuntu keep the plain Linux look for now.make debugcan simulate all four.A value from
colors.tomlis six hex digits or it is dropped, since a theme comes from any git repository and lands in an inline<style>. Pinning Light or Dark against the theme's scheme leaves the page out of the theme.What taking it to a real Omarchy machine cost
The checkout could not be built or debugged there at all, so six fixes ride along. Each was found by hitting it, in this order:
.cache/adminer-src.zipcarried no version, so make saw the file and called it up to date: a machine that had built before 6.1.1 kept its 5.5.1 zip forever andmake fetchdied in the extract, on a path no message explained. The name carries the version now.webkit2gtk-4.0, which Ubuntu dropped in 24.04 and Arch never had; the shim onto 4.1 was written into/usrbylinux-deps, which also refused any distro without apt. It goes to.cache/pkgconfignow, reached through an exportedPKG_CONFIG_PATH— a build artifact, no root — andlinux-depsasks whether the headers are installed before it asks which package manager is present, so Arch and Fedora build and are told what to install when they cannot.-debugturned nothing on off macOS.enableInspectorwas a!darwinstub returning false, so the one instruction this repo gives for debugging — do not guess, open the inspector — had no meaning on Linux. WebKitGTK has an inspector of its own, and-debugnow makes it available the way macOS does: available, not open. F12 or Ctrl+Shift+I opens it in a window of its own, taken on the GtkWindow so it works with the caret in a textarea. Console messages reach stdout, and so the log, whether it is open or not — which is what is left when the page dies before you get to it.loaderShown, and on WebKitGTK 2.54 nothing from the page reaches Go at all — so everymake runthere showed no window for the whole run while the server came up, served the page and logged a clean startup behind it. A two-secondsync.Oncedeadline is the floor under that reveal, and says in the log when it fires.kill-orphanswas a no-op on Linux. It recognised an orphan by ppid 1, which is never true wheresystemd --useris a subreaper: it reported "no orphaned frankenphp server" while fourteen of them held fourteen ports, which is the one failure it exists to prevent.PHP_BINARY, which the Linux frankenphp leaves empty andproc_openrefuses, so the file was never checked and nothing said so.All six are Linux-only in effect: the shim and
linux-depssit behindifeq ($(UNAME_S),Linux), the inspector is one definition per platform (menu_darwin.go/inspector_linux.go/inspector_other.go, whichmake qa's platform-stub guard enforces), and the reaper set is still just init where there is no systemd.Two things the real machine then showed
Running it on Omarchy is also the only reason these were found, and both are in here:
--ad-ok, and a palette replaces that token with the theme's owngreen— a colour chosen to be read as text on the background, not to be a surface (Tokyo Night's#9ece6a). It now wears what.messagewears: the green as text over--ad-ok-bg. Measured across the 23 themes installed on that machine rather than judged on one — that pairing clears 4.5:1 on 19 of them, against 16 for a tint mixed from the theme's own background, which was the other candidate. The four it misses have a muted green and.messagehas the same contrast there today, so that is one fix for both and not this one.rounding = 0and a theme does not touch it, so the window around this one has hard corners while every panel, input and button inside carried a 7px radius. The two radius tokens carry most of it; the rest is a short list that bypasses them. Discs stay discs.What is still not checked
The app builds, runs and is debuggable on a real Omarchy machine now, and the page has been looked at there — that is where the two above came from. The Ubuntu, Kubuntu and Mint sheets have still only been seen in Chromium on macOS through the simulation. No source shows what Kubuntu's
os-releasesays, soubuntuandkubuntuboth count. Some window and border colours were worked out by hand from the themes' Sass, as the sheets' comments say. This changes colours only, not sizes, radii or fonts. White on Breeze's and Yaru's accent is low contrast on primary buttons, as it is in those themes.make qaandmake checkpass on macOS and on Arch, andmake e2eon macOS.tests/cli/OmarchyThemeTest.phpcovers reading a theme and refusing what is not a colour. No e2e scenario covers the new sheets, and none coversTheme::cssMap()honouring the theme's scheme.make checkused to fail on an Omarchy machine whose theme is dark, and that is fixed here. The boot check posts a light and a dark design and expects both back media-gated, which cannot hold once Auto follows the theme's scheme — so it was green in CI and on macOS, green onmain, and red only for whoever ran it on Omarchy, which reads as a regression in whatever that person last touched. Its server now getsHOMEpointed at the throwaway data dir it already makes and removes, so every machine answers as CI does; the e2e fixture, which boots the same app for the light and dark theme scenarios, takes the same line.