DesktopTileLauncher
A lightweight Windows desktop launcher for quickly opening frequently-used apps, folders, and links — built as a sandbox for GenAI-assisted development + release discipline.
Quick demo
Screenshot
⬇️ Download the latest release
Install
WinGet (recommended)
winget install --id 108thecitizen.DesktopTileLauncher -e
Upgrade
winget upgrade --id 108thecitizen.DesktopTileLauncher -e
Uninstall
winget uninstall --id 108thecitizen.DesktopTileLauncher -e
Why this exists / what I learned
- Built to reduce daily friction: a lightweight Windows desktop launcher for quickly opening frequently-used apps, folders, and links.
- Used as a sandbox for AI-assisted development and agent workflows — iterating with Codex/ChatGPT/Claude and capturing “how to work on this repo” conventions in
AGENTS.md.
- Reinforced “ship means stable”: small diffs, PR-friendly iteration, and automated checks so changes stay predictable as the project evolves.
- Reinforced “ship means safe” with GitHub Actions (tests + lint/typecheck), CodeQL, Dependabot, and tag-based releases.
- Practiced release discipline: tag-driven releases via GitHub Actions, plus a documented path toward signed binaries so end-user downloads can be trusted.
- Biggest takeaway: AI can accelerate iteration, but automation + clarity (tests/CI + explicit conventions) are the real guardrails.
Code signing policy
Free code signing provided by SignPath.io, certificate by SignPath Foundation.
Status & activation
As of 2025‑09‑05, released binaries are not yet signed. We plan to begin signing starting with release tag v0.7.0 (and all tags thereafter). This section documents how signed releases will be produced and how you can verify them.
Scope (what we sign)
We sign Windows desktop artifacts intended for end users:
- the main executable
DesktopTileLauncher-.exe published on the GitHub Releases page.
- for onedir builds, the executable(s) inside the folder; the
.zip is a packaging container and is not Authenticode-signed. Verify the zip via checksums.
Intermediate CI artifacts may remain unsigned unless explicitly marked. Source code tarballs generated by GitHub are not signed.
Provenance & build process
Releases are built from Git tags in this repository via GitHub Actions. We stamp version info from the tag (ProductVersion/FileVersion) and embed standard metadata (ProductName: “DesktopTileLauncher”). Signing occurs in CI after the final EXE is produced and before checksums are computed and published.
Signing method
We use Authenticode with an RFC‑3161 timestamp so signatures remain valid after certificate expiry. The signing certificate is held by SignPath Foundation and used only for approved builds of this project.
Roles & approvals
Authors/Committers: 108thecitizen
Review/Approval for release signing: 108thecitizen
External pull requests are reviewed before merge; only tagged builds from main are submitted for release signing.
Privacy
DesktopTileLauncher does not collect telemetry. Network access is limited to user-initiated actions: opening a tile URL in your browser, and adding or editing a URL tile may fetch a site icon through Google's favicon service. That favicon lookup may make a third-party network request and may send the tile's domain/host to the favicon service. See Debugging & Crash Reports for local log locations.
Uninstall
Delete the application folder. Optionally remove per‑user logs/config in the directories listed in the README.
Verification (how to check a signed release)
- Windows UI: Right‑click the EXE → Properties → Digital Signatures tab.
- PowerShell:
Get-AuthenticodeSignature .\DesktopTileLauncher-.exe | Format-List
- SignTool (if installed):
signtool verify /pa /v .\DesktopTileLauncher-.exe
- Checksum: Compare against SHA256SUMS.txt published with the release:
Get-FileHash .\DesktopTileLauncher-.exe -Algorithm SHA256
Security & incident response
If we ever discover a compromised artifact or certificate, we will (a) revoke the affected release, (b) publish a GitHub Security Advisory with details and mitigation steps, and (c) rotate credentials and re‑issue a fixed build. Please report vulnerabilities privately via GitHub’s “Report a vulnerability” link.
Last updated: 2025‑09‑05
License
Licensed under the Apache License, Version 2.0. See LICENSE for details.
Prior releases were MIT; the text is preserved in LICENSE-MIT.
SPDX-License-Identifier: Apache-2.0
Usage
Add tiles
- Use the Add button on the toolbar.
- Right-click whitespace within a tab and choose Add Tile….
On Windows, selecting Google Chrome for a tile (or leaving the browser as
Default when Chrome is the system default) reveals a Chrome profile
dropdown. The list is populated from Chrome's local profile cache and includes
entries like Default, Profile 1, or names from signed-in Google accounts.
Choosing a profile pins the tile to that persona; select None to use
Chrome's last-used profile.
Each tile also provides an Open in option:
- New tab in existing window (default)
- New browser window
For Chromium browsers (Chrome/Edge), a new window adds the --new-window
switch. Firefox uses --new-tab or --new-window. If the tile targets the
system's default browser, Python's webbrowser.open is used with new=2 for a
tab or new=1 for a window. Safari and other unknown browsers fall back to
this behavior and may not differentiate between tabs and windows.
On Windows when the chosen browser is Chrome (either explicitly or because it's
the system default), the launcher invokes Chrome's command-line interface to
ensure "New browser window" always opens a separate top-level window.
Existing configurations that lack this setting are automatically migrated and
default to opening URLs in a new tab.
Auto-fit window
The View → Auto-fit Mode submenu controls how the launcher resizes itself:
- Always – recompute and resize on every move or display change.
- On startup – fit once at launch (default), then allow manual resizing.
- Off – never auto-resize; the window remembers its size and position.
Choose View → Fit to Display Now for a one-off fit regardless of the
current mode.
Debugging & Crash Reports
DesktopTileLauncher writes JSON logs to a rotating debug.log in a per-user
directory:
- Windows:
%LOCALAPPDATA%/DesktopTileLauncher/
- macOS:
~/Library/Logs/DesktopTileLauncher/
- Linux:
$XDG_STATE_HOME/DesktopTileLauncher/ or
~/.local/state/DesktopTileLauncher/
Aside from user-initiated URL opens and optional favicon lookups described
above, the application does not send logs or crash data over the network. When
something goes wrong, use the Create Crash Bundle button on the crash dialog
to zip the log files and a crash.json snapshot of runtime context. Attach this
bundle when filing a GitHub issue.
Running unit tests offline (Codex / air‑gapped)
We vendor Linux wheels under vendor/wheelhouse-linux/ (PySide6 wheels are split into *.whl.part-* to stay under GitHub’s 100 MB limit).
One-liner:
bash tools/offline_bootstrap.sh
# or:
make test_unit_offline