The repo had no upstream ancestry: a whole tree arrived in one commit in May, so
every update meant re-applying our patches by hand onto a fresh checkout, and a file
Element moved would take our lines with it silently.
The real base was found by measuring tree distance across develop rather than trusting
the changelog: deadd548, not the v1.12.17 tag. With that set as a temporary graft, this
merge computed as a proper three-way merge - 32 conflicts instead of 1757.
Resolutions, each decided rather than defaulted:
- 24 GitHub workflows stay deleted; we build on GitLab CI.
- MImageBody.tsx is gone upstream, migrated to MVVM. Our ClamAV error label moved into
ImageBodyViewModel.computeErrorLabel, ahead of the DecryptError branch, matching what
VideoBodyViewModel and FileBodyViewModel already do.
- Upstream extracted the room list item body into RoomListItemContent. Our call
participants list and its getInitials helper moved there; both sides' CSS classes and
both sides' props are kept.
- matrix-js-sdk follows upstream at 42.2.0 - our git ref pin was a workaround for a
stale ref, and following upstream is the point of this merge.
- Element Call stays ours. Checked before deciding: @element-hq/element-call-embedded
is referenced nowhere in the tree, while webpack.config.ts needs
@sorb/threadnet-call-embedded, so taking upstream's line would have deleted the noise
suppression from #0054 without a word.
The lockfile was regenerated with pnpm 11.20.0, which upstream now requires through
devEngines. CI already runs corepack enable, and onFail: download makes it fetch that
version by itself.
Not yet accepted: this needs a build and the ClamAV functional test - send an encrypted
file, receive a rejected one - before it goes near main.
Decision sorb. The desktop client loads this config.json rather than the one the web
deployment serves, so setting it in element-values.yaml alone would have hardened the
web client and left the builds that actually get handed out untouched - the same trap
as the themes rollout.
It hides the edit button next to the server name, so the homeserver cannot be changed
through the interface, and it makes the 401/403 login error name the server instead of
staying generic.
Stated in the comment rather than discovered later: this is a surface restriction, not
a technical one. MatrixChat still accepts hs_url from the query string in the mobile
registration and registration-confirmation paths without consulting the setting. It
narrows the way to GHSA-wrcp-5v3v-3j6v, which affects everything below 1.12.22 while
we run 1.12.17, and it does not replace the upstream update that management #0099 is
actually about.
Takes effect with the next desktop build.
Electron's save dialog offers only "All Files" unless it is handed filters,
so someone who replaced "photo.jpg" with "photo" got a file with no extension
at all and no way to open it. The browser does not do this: it offers the
file's own type, and puts the extension back when the name arrives without
one.
The download now names its type before the dialog goes up, and the "Save
image as..." context menu passes the same filters. A file with no extension
to preserve is left alone rather than being given a meaningless filter, and
"All Files" stays on the list so anyone who really wants an extensionless
name can still pick it.
Tests: a download with an extension gets filters, one without does not, and
the context menu path is covered as well.
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
The desktop variant had no bug_report_endpoint_url at all, so the whole section stayed hidden and a desktop user could not produce logs for a report. Setting local shows a Download logs button that writes them to the device and uploads nothing.
Matches what the web client now serves. Takes effect with the next desktop build.
Refs axion1337.chat/ThreadNet-Web#9
Die heute im Web gesetzten branding-Werte fehlten der Desktop-Config. Ohne sie
faellt AuthHeaderLogo.tsx auf themes/element/img/logos/element-logo.svg zurueck -
die Anmeldemaske des Desktop-Clients haette also weiter Elements gruenes Logo
gezeigt, waehrend der Web-Client bereits die ThreadNet-Marke traegt.
vector-icons/512.png liegt im webapp-Bundle des Desktops (geprueft), der Pfad
loest also auch dort auf.
Chirurgisch eingefuegt, nicht neu serialisiert - die 17 Themes und der
Gedankenstrich in der Beschreibung bleiben unangetastet.
Danach gilt: Web-Konfiguration ist eine echte Teilmenge der Desktop-Konfiguration,
ohne einen einzigen Wertkonflikt (verglichen ueber alle verschachtelten
Schluessel).
Refs ThreadNet-Web#1
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Upstream setzt mac.icon auf build/icon.icon - das Icon-Composer-Bundle von
macOS 26. Dessen Verarbeitung ruft actool auf, das es nur mit dem vollen Xcode
gibt (~10 GB, App-Store-Login). Mit blossen CommandLineTools scheitert damit
JEDER macOS-Build:
⨯ Failed to check actool version. Is Xcode 26 or higher installed?
Die bisherige Diagnose in management#22 war falsch: Dort stand, nur das
DMG-Target brauche actool und das ZIP baue problemlos. Tatsaechlich trifft es
alle macOS-Targets, weil mac.icon fuer alle gilt - das ZIP scheitert genauso.
Der dort empfohlene Ausweg (DMG per hdiutil bauen) haette ein Problem geloest,
das gar nicht am DMG lag.
Loesung: mac.icon und dmg.badgeIcon auf das klassische build/icon.icns. Damit
baut electron-builder ZIP UND DMG selbst, inklusive Blockmap - verifiziert am
2026-08-06, beide Artefakte in Release v0.4.1.
Umgesetzt als Variantenoption statt als Aenderung an Upstreams Defaults: Die
Werte stehen in unserem axion1337/build.json, electron-builder.ts wird nur
additiv um zwei optionale Schluessel erweitert - dieselbe Machart wie das
bereits vorhandene linux.deb.name. Ein Upstream-Merge erzeugt an der
mac.icon-Zeile damit keinen Konflikt.
Preis: kein macOS-26-Icon-Rendering. Ohne Xcode gaebe es ohnehin keinen Build.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Zwei Haelften desselben Issues, bewusst in einem Commit, weil sie zusammen
gebaut und ausgeliefert werden.
Desktop-Icons: build/icon.png war byte-identisch mit dem alten, unzentrierten
Web-Icon - das Motiv klebte an der Oberkante (Rand oben 3 %, unten 40 %). macOS
und Windows zeigten also dasselbe schiefe Bild wie der Browser-Tab. Alle vier
Artefakte aus der jetzt zentrierten Quelle neu erzeugt: icon.png, icon.ico
(sieben Groessen von 16 bis 256), das Layer-Asset des macOS-Icon-Composers und
icon.icns ueber iconutil (10 Einzelbilder, 16-512 plus @2x). Alle vier gehen auf
dieselbe Datei zurueck, sie koennen also nicht mehr auseinanderlaufen.
About-Attribution: 'ThreadNet - powered by Element' steht jetzt in Einstellungen
-> Hilfe & Info direkt unter der Client-Version, mit Link auf element.io. Das
war der eigentliche Zweck des Issues - bisher stand die Zeile nur in der
Build-Beschreibung des Desktop-Pakets und war im Client nirgends sichtbar.
Zwei bewusste Entscheidungen dabei, beide im Code kommentiert:
- NICHT in getVersionTextToCopy aufgenommen. Der Text dort landet in
Fehlerberichten; die Herkunft des Forks ist da nur Rauschen.
- Ohne _t(). Ein Markenhinweis wird nicht uebersetzt, und jeder zusaetzliche
i18n-Schluessel ist Reibung beim naechsten Upstream-Merge - genau das, was das
Issue mit 'chirurgisch halten' meint.
Das Stylesheet nutzt nur Variablen, die im Projekt bereits verbreitet sind
(--cpd-space-2x in 43, --cpd-color-text-secondary in 28,
--cpd-font-body-sm-regular in 22 Dateien) - kein Blindflug mit erfundenen Tokens.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Pressing "Open" on the download-complete toast called shell.openPath and discarded the
result with `void`. openPath resolves to a non-empty error string on failure (an empty
string means success), so when the file had been moved or deleted the open silently did
nothing and the user saw no response at all (#32273).
Await the result and, on a non-empty error, log it and show an error dialog carrying the
underlying error as its detail.
Co-authored-by: R Midhun Suresh <hi@midhun.dev>
Die zehn theme-factory-Themes sind jetzt in beiden Configs identisch (gitops
c47b0a3 + Nachfolger). Ohne das haetten Desktop-Clients weiter meine alte
Interpretation der Paletten gezeigt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
electron-builder leitet unterschiedliche Dinge aus zwei Feldern ab: productName
bestimmt den App-Namen (macOS .app, Windows Setup.exe), 'name' dagegen den
Linux-Paketnamen, das Binary und den /opt-Pfad. Nach dem Rebrand hiess die App
ueberall ThreadNet - ausser bei .deb und .tar.gz.
Nebenwirkung bewusst in Kauf genommen: apt sieht ein neues Paket, ein
Upgrade-Pfad von element-desktop existiert nicht. Bei einem Rebrand ist das
erwartbar; die appId bleibt unveraendert, damit lokale Daten erhalten bleiben.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Gestern wurden nur icon.png und icon.icns getauscht; Windows (.ico) und der
Web-Client (res/vector-icons/, manifest.json) trugen weiter das Element-Icon.
Dazu ein echter Fehler behoben: die Icons wurden mit PIL.thumbnail() erzeugt -
das skaliert NUR nach unten. Das 277px-Motiv wurde in 1024er-Icons daher nie
vergroessert und fuellte ueberall bloss 54% x 38% der Flaeche. Jetzt mit resize()
aus dem 1024er-Original: 81% Breite statt 54%.
Ersetzt: web/res/vector-icons/{24,120,144,152,180,512,1024}.png, manifest.json
(name/short_name -> ThreadNet), desktop/build/icon.{png,ico,icns}.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Erster Schritt aus ThreadNet-Web#10 - der Client hiess bisher 'Element' und
zeigte dessen Icon.
- apps/desktop/axion1337/build.json: eigene Build-Variante (VARIANT_PATH), damit
element.io/release/build.json unangetastet bleibt und Upstream-Merges nicht
reiben. productName 'ThreadNet', Beschreibung 'ThreadNet - powered by Element'
als faire Attribution (Element Web ist AGPL, dies ist ein Fork davon).
- appId bleibt bewusst 'im.riot.app': bestehende Installationen behalten ihre
lokalen Daten. Ein appId-Wechsel waere ein Datenschnitt und gehoert in die
Rebranding-Runde, nicht in einen Icon-Commit.
- build/icon.png + icon.icns: ThreadNet-Bildmarke, transparenter Rand entfernt
(das Motiv fuellte im Original nur 54% x 38% - direkt skaliert verschwindet es).
Verifiziert im Build: CFBundleName/CFBundleDisplayName = ThreadNet, eigenes
Icon, alle 17 Themes im webapp.asar.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Die Desktop-Apps laden ihre eigene config.json und haetten die elf neuen Themes
sonst nicht (aXion1337 Light + zehn Paletten). Aus der bereits deployten
Web-Konfiguration uebernommen, damit beide Clients identisch sind.
Chirurgisch eingefuegt (Lehre vom 2026-08-01, als ein Re-Dump dieser Datei 441
Zeilen umformatierte): 0 entfernte / 427 neue Zeilen, JSON validiert.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Aus artifactDownloader.go + binDownload.js verifiziert: Schluessel ist
<release>-<release>, Unterverzeichnis = Namensteil vor dem ersten
Bindestrich (nsis-resources daher unter nsis\). Job 431 traf winCodeSign
im Cache, scheiterte aber am nsis-Miss mit einfachem Namen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
winCodeSign starb an denselben CDN-Resets wie zuvor die Electron-Binary
(Job 424); Prefetch-Skript konsolidiert Electron-Zip + winCodeSign +
NSIS-Pakete mit curl -C - in die persistenten Caches (ELECTRON_CACHE,
ELECTRON_BUILDER_CACHE).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
First CI for the lab GitLab (git.lab): web job builds the webapp with the
lessons from the Gitea attempts baked in (frozen-lockfile instead of
layered.sh, 6GB node heap), docker_web pushes the canonical
apps/web/Dockerfile image to the rohana registry that Flux pulls from,
and two manual jobs cover the desktop path - a dockerbuild build-image
and the Electron Linux build replicating the manually verified flow.
Also tracks the production client config (apps/desktop/axion1337/) that
previously only existed inside the one-off manual desktop build.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The earlier script-permission fix (5e3254d) only covered scripts
invoked by apps/web's own Dockerfile/CI at the time. Found 9 more
non-executable scripts (644 instead of 755) while building the
Electron desktop app via apps/desktop/dockerbuild - same root cause,
different invocation paths.
Draw a styled 32px macOS title bar
Replace the per-surface drag-strip hacks with a single full-width title
bar band matching the design: canvas background, hairline separator, and
draggable. Recentre the traffic lights for the taller band. Dialogs and
floating overlays stay clickable when they reach into the band while the
rest of the bar remains draggable.
* Fix some documentation for element-desktop
Some of these links got broken, or outdated, during the monorepo switch.
* Fix desktop docker build script
It will fail with 'workspace_node_modules: no such file or directory' if the
directory does not exist.
This got broken by https://github.com/element-hq/element-web/pull/33641.
* Clarify native modules doc
Most of this stuff does not apply when using the docker build.
* update snapshot
* Widen the macOS title-bar drag strips so the window is easy to move
With titleBarStyle: "hidden" there is no native title bar, so the macOS window can only be
moved via the -webkit-app-region: drag strips above the room and left-panel headers. Those
strips were only ~13-24px tall and too thin to reliably grab, making the window awkward to
move.
Raise the drag strips above the room, left-panel and space headers to 32px (matching the
traffic-light offset already used elsewhere in the file) for a comfortable grab zone;
interactive controls keep -webkit-app-region: no-drag so they stay clickable. The injected CSS
is also extracted into a pure buildTitleBarCss() helper so the string contract can be
unit-tested.
* Address review: use author copyright, cover setupMacosTitleBar, drop dead selector
Use my own copyright on the new test file rather than New Vector's.
Add tests for setupMacosTitleBar() itself: the platform guard and the
enter-full-screen / leave-full-screen / did-finish-load lifecycle were
previously never executed, leaving the diff below the 80% coverage gate.
Drop the .mx_LeftPanel_newRoomList::before rule: #34040 removed that class
from the product, so the rule matched nothing and the border-right it carried
was silently lost from the left panel. Fold it back into .mx_LeftPanel::before,
with a regression test covering the separator.
---------
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* Space the collapsed space panel separator away from the macOS traffic lights
On macOS the frameless window draws the traffic light buttons over the top
of the space panel. The cluster is inset 9px and is roughly 52px wide, so it
ends about 61px from the window edge. The collapsed space panel is 68px wide,
which left its right-hand separator crowding the green button.
Widen the collapsed panel to 76px on macOS so the separator gets about 15px
of clearance, in line with the compound 4x spacing step. The rule is added to
the styling already injected for the macOS title bar, so it only affects the
desktop app on macOS and is removed in full screen along with the rest.
Fixes https://github.com/element-hq/element-web/issues/32012
Notes: Fix the collapsed space panel separator sitting too close to the macOS traffic light buttons.
* Use contributor copyright header on the new test file
Thore Cimbal
RiotRobot
Richard van der HoffandGitHub
keeharandGitHub