Open Source · Agentisch entwickelt · Python + PyQt6

Ein Memtime-Klon — gebaut von 5 KI-Agenten

Wie ein vollständiges Desktop-Zeiterfassungs-Tool entsteht, wenn man die Aufgabe konsequent in spezialisierte Agenten aufteilt — und was dabei zu lernen ist.

GitHub-Repo ansehen Die 5 Agenten →
bash install.sh
# Einmalige Installation auf Mac oder Linux
$ curl -fsSL https://memtime-nachbau.hiltmann.cloud/install.sh | bash
 
Erkanntes System: Darwin (macos)
Python 3.12.3 gefunden
Klone Repo nach ~/timetracker ...
Erstelle virtuelle Umgebung (.venv)
Abhängigkeiten installiert
 
✅ Installation abgeschlossen!
 
# App starten:
$ ~/timetracker/start.sh

⏱ Das Projekt

Memtime nachbauen — warum und wie?

Memtime ist ein macOS/Windows-Tool, das automatisch aufzeichnet, in welcher App und welchem Dokument man wann gearbeitet hat — ohne manuelles Starten. Dieses Projekt baut genau das nach: open source, plattformübergreifend, mit KI-Analyse.

🔍

Automatisches Tracking

Pollt im Hintergrund aktive App und Fenstertitel. Schreibt Zeitblöcke in SQLite — lückenlos, ohne Useraktion.

📸

Screenshot-Analyse

Macht alle 10 Sekunden einen Screenshot und schickt ihn an ein lokales Ollama-Modell. Das KI-Modell beschreibt in 1–2 Sätzen, womit man gerade beschäftigt war.

📊

Timeline & Reports

24-Stunden-Tagesansicht wie in Memtime, Aktivitätsliste, Projektpanel, CSV/JSON-Export — vollständige PyQt6-UI.

🖥️

Mac & Linux

Native Plattformadapter: macOS via pyobjc/Quartz, Linux via python-xlib/ewmh. Ein Codebase, zwei Plattformen.

🔒

100 % lokal

Keine Cloud, kein Server, keine Subscription. SQLite-Datenbank im Home-Verzeichnis. KI via lokalem Ollama.

📦

One-Line-Install

Ein Bash-Script clont das Repo, erstellt die virtuelle Umgebung und installiert alle Abhängigkeiten — auf Mac und Linux gleich.


🤖 Agentische Entwicklung

5 Agenten — ein Projekt

Statt einen einzigen KI-Agenten alles bauen zu lassen, wurde das Projekt konsequent in 5 spezialisierte Agenten aufgeteilt. Jeder Agent hat einen klaren Scope, klar definierte Schnittstellen zu den anderen — und arbeitet unabhängig.

Das Prinzip: Kein Agent kennt die Implementierungsdetails der anderen. Er kennt nur die Schnittstellen (Funktionsnamen, Datenmodelle, DB-Schema). Das erzwingt saubere Modularität — genauso wie bei echten Teams. Der Architekt-Agent schreibt das Pflichtenheft, alle anderen halten sich daran.

Agent 01 / 05
Architekt-Agent
System Design
Plant das Gesamtsystem, definiert Schnittstellen, legt das DB-Schema fest — bevor eine einzige Zeile Code geschrieben wird.
database/models.py database/db.py requirements*.txt

Aufgaben & Entscheidungen

Modulstruktur festlegen

5 Module definiert: tracker/, database/, ai/, ui/, utils/ — mit klaren Verantwortlichkeiten und keinerlei Querabhängigkeiten außer über database/.

SQLite-Schema entwerfen

Tabellen: activities, projects, screenshots, analysis_queue, blocklist, settings. Mit Indizes, WAL-Mode und Thread-Safety-Lock (DB_LOCK).

Plattformstrategie

Platform-Abstraktionsschicht: tracker/platform/__init__.py wählt zur Laufzeit mac- oder Linux-Implementierung. Kein plattformspezifischer Code außerhalb dieser Schicht.

Phasen-Roadmap

Phase 1: Headless-Tracker. Phase 2: Timeline-UI. Phase 3: Projekte, Reports, Export. Phase 4: KI-Analyse. Jede Phase lieferbar ohne die nächste.

Agent 02 / 05
Tracker-Agent
Plattform & Tracking
Implementiert den Kern: den Polling-Loop, Plattformadapter für Mac und Linux, Idle-Erkennung und Screenshot-Capture.
tracker/activity_tracker.py tracker/platform/macos.py tracker/platform/linux.py tracker/idle_detector.py tracker/screenshot.py

Aufgaben & Entscheidungen

Polling-Loop im Background-Thread

ActivityTracker läuft in einem Daemon-Thread. Konfigurierbare Polling-Frequenz (Standard: 1 Sekunde). Stop-Event statt forcess Kill.

macOS via pyobjc + Accessibility API

NSWorkspace für App-Namen, AXUIElement für Fenstertitel, AppleScript-Bridge für Browser-URLs. Idle-Zeit via CGEventSource.

Linux via X11 (ewmh + python-xlib)

Aktives Fenster über _NET_ACTIVE_WINDOW, WM_CLASS für App-Namen, XScreenSaver für Idle-Zeit. Browser-URL-Tracking nicht unterstützt.

Crash Recovery

Beim Start werden alle Aktivitäten mit NULL end_time geschlossen — robust gegen harte Abstürze ohne Datenverlust.

Agent 03 / 05
Datenbank-Agent
Persistenz & Queries
Implementiert die gesamte Datenschicht: Schema, Thread-sichere Verbindung, CRUD-Operationen und alle SQL-Queries der anderen Module.
database/db.py database/models.py utils/export.py

Aufgaben & Entscheidungen

SQLite-Singleton mit WAL-Mode

Eine globale Verbindung pro Prozess (thread-safe via check_same_thread=False + DB_LOCK). WAL-Mode für bessere Nebenläufigkeit.

Plattformspezifische DB-Pfade

macOS: ~/Library/Application Support/TimeTracker/. Linux: ~/.local/share/TimeTracker/. Automatisch erstellt bei erstem Start.

Settings-System

Key/Value-Tabelle für alle Konfigurationen (poll_interval_ms, screenshot_interval_sec, idle_threshold_minutes, ai_analysis_enabled etc.) mit Defaults.

Export: CSV & JSON

export_csv() und export_json() mit Datumsbereich-Filter. JSON: verschachtelt nach Tag. CSV: flach mit allen Feldern inkl. ai_hint.

Agent 04 / 05
UI-Agent
Desktop-Interface
Baut die gesamte PyQt6-Oberfläche: Hauptfenster, Timeline, Aktivitätsliste, Reports, System-Tray und alle Dialoge.
ui/main_window.py ui/timeline_view.py ui/activity_list.py ui/reports_view.py ui/project_panel.py ui/settings_dialog.py ui/tray_icon.py ui/screenshot_viewer.py

Aufgaben & Entscheidungen

Thread-sichere UI-Updates via PyQt6-Signals

Der Tracker-Thread ruft on_activity_update() auf → emit _refresh_signal → UI-Thread refresht Timeline. Kein direktes UI-Update aus Background-Threads.

Custom-painted Timeline (QWidget + QPainter)

24h-Achse, farbkodierte App-Blöcke, Zoom-Stufen, Hover-Tooltips, Click-to-select. Kein Framework — reines QPainter-Canvas.

System-Tray mit Minimize-to-Tray

App bleibt beim Schließen im Tray. QApplication.setQuitOnLastWindowClosed(False). Tray-Icon wechselt Farbe bei Pause.

Settings-Dialog mit 6 Tabs

Tracking, Screenshots, KI-Analyse, Datenschutz/Blocklist, Interface, Daten & Export — alle Einstellungen über die DB-Settings-Tabelle persistiert.

Agent 05 / 05
KI-Agent
AI-Analyse & Integration
Integriert lokale KI-Analyse via Ollama, schreibt den Installations-Workflow und stellt sicher, dass alle 5 Module sauber zusammenspielen.
ai/analyzer.py main.py install.sh requirements*.txt

Aufgaben & Entscheidungen

ScreenshotAnalyzer mit Ollama-Backend

Eigener Background-Thread pollt analysis_queue alle 10 Sekunden. Sendet Screenshot als Base64 an lokales Ollama (Standard: gemma3:4b). Speichert ai_hint zurück in die DB.

Konfigurierbare Verzögerung

ai_analysis_delay_sec (Standard: 30s) verhindert CPU-Spitzen direkt nach Screenshot. Modell, Server-URL und Delay per Settings konfigurierbar.

Graceful Degradation

KI-Analyse ist optional (Standard: deaktiviert). Wenn Ollama nicht läuft, bleibt ai_hint leer. App funktioniert vollständig ohne KI.

Plattform-übergreifendes Install-Script

Erkennt macOS vs. Linux, installiert korrekte requirements, erstellt start.sh, führt Headless-Test durch und gibt Accessibility-Hinweis auf macOS.


🔄 Das Prinzip

Wie agentische Entwicklung funktioniert

Nicht ein Agent für alles — sondern ein klarer Prozess, bei dem jeder Agent auf dem Ergebnis des vorherigen aufbaut.

Schritt 01
Architektur zuerst
Architekt-Agent legt Modulstruktur, DB-Schema und Schnittstellen fest. Noch keine Implementierung.
Schritt 02
Parallele Umsetzung
Tracker- und Datenbank-Agent arbeiten gleichzeitig. Beide kennen das Schema, nicht gegenseitigen Code.
Schritt 03
UI auf Basis der API
UI-Agent konsumiert nur die öffentliche DB-API. Kein Wissen über Tracker-Interna. Klare Trennung.
Schritt 04
KI als Add-on
KI-Agent ergänzt ai_hint-Feld und analysis_queue — ohne bestehende Module zu verändern. Additiv, nicht invasiv.
Schritt 05
Integration testen
main.py --headless als Integrations-Test. Alle Module zusammen, 30 Sekunden, ohne UI — Smoke Test.

📁 Architektur

Struktur des Projekts

Jedes Modul hat genau eine Verantwortung. Abhängigkeiten fließen nur in eine Richtung: alle Module → database/, nie untereinander.

Dateistruktur

memtime-nachbau/
 ├── main.py ← Einstiegspunkt
 ├── tracker/
 │   ├── activity_tracker.py
 │   ├── idle_detector.py
 │   ├── screenshot.py
 │   └── platform/
 │       ├── macos.py
 │       └── linux.py
 ├── database/
 │   ├── db.py
 │   └── models.py
 ├── ai/
 │   └── analyzer.py
 ├── ui/ ← 8 Dateien
 ├── utils/
 │   └── export.py
 ├── requirements.txt
 ├── requirements-macos.txt
 └── requirements-linux.txt

Tech-Stack

PyQt6 Desktop-UI
SQLite + WAL Datenbank
pyobjc / python-xlib Plattformadapter
mss + Pillow Screenshots
Ollama + gemma3:4b Lokale KI
Python 3.11+ Basis

💾 Daten-Speicherort:
macOS: ~/Library/Application Support/TimeTracker/
Linux: ~/.local/share/TimeTracker/


🚀 Installation

In 3 Minuten lauffähig

Ein Script, zwei Plattformen. Läuft auf macOS und Linux ohne manuelle Konfiguration.

Option A – One-Liner (empfohlen)
$ curl -fsSL https://memtime-nachbau.hiltmann.cloud/install.sh | bash
Option B – Script herunterladen & prüfen
$ curl -O https://memtime-nachbau.hiltmann.cloud/install.sh
$ cat install.sh # Inhalt prüfen
$ bash install.sh
Accessibility-Rechte (einmalig)
# macOS fragt beim ersten Start automatisch:
Systemeinstellungen → Datenschutz & Sicherheit → Bedienungshilfen → Terminal ✓
Voraussetzungen
$ sudo apt install python3 python3-pip python3-venv git
Installation
$ curl -fsSL https://memtime-nachbau.hiltmann.cloud/install.sh | bash
Hinweis: X11 erforderlich
# Wayland wird (noch) nicht unterstützt
# Auf Ubuntu 24.04: XWayland ist standardmäßig aktiv → funktioniert
1 – Repo clonen
$ git clone https://github.com/uh8888/memtime-nachbau.git
$ cd memtime-nachbau
2 – Virtuelle Umgebung
$ python3 -m venv .venv
$ source .venv/bin/activate
3 – Abhängigkeiten (macOS)
$ pip install -r requirements.txt -r requirements-macos.txt
3 – Abhängigkeiten (Linux)
$ pip install -r requirements.txt -r requirements-linux.txt
4 – Starten
$ python main.py --headless # Funktionstest (30s)
$ python main.py # Vollständige UI

Optional: KI-Analyse via Ollama
Nur nötig wenn du die Screenshot-Analyse aktivieren möchtest (Standard: deaktiviert).

# macOS
$ brew install ollama && ollama pull gemma3:4b && ollama serve
# Linux
$ curl -fsSL https://ollama.com/install.sh | sh && ollama pull gemma3:4b

💡 Was wir gelernt haben

Lektionen aus agentischer Entwicklung

Was funktioniert, was nicht — und was jeder mitnehmen kann, der diesen Ansatz für eigene Projekte nutzen möchte.

Architektur vor Code

Der Architekt-Agent als erste Instanz verhindert das größte Problem: Agenten, die in verschiedene Richtungen bauen. DB-Schema und Interfaces zuerst — dann erst Implementierung.

🔌

Schnittstellen statt Implementierungen

Jeder Agent kennt nur die Funktionssignaturen der anderen, nicht deren Code. Das erzwingt saubere Modularität — genau wie echte Teams, die nicht gegenseitig in den Code schauen.

📦

Jede Phase muss lieferbar sein

Phase 1 (Headless-Tracker) lief ohne UI. Phase 2 (Timeline) lief ohne Projekte. Additives Vorgehen macht jeden Schritt testbar und verhindert Blockaden.

🧪

Headless-Test als Qualitäts-Gate

main.py --headless ist der Smoke Test: Startet alles, trackt 30 Sekunden, schreibt in die DB. Schlägt das fehl, gibt es ein Integrationsproblem — bevor die UI es versteckt.

KI additiv, nicht invasiv

Der KI-Agent hat kein einziges bestehendes File verändert. Neue Tabelle (analysis_queue), neues Feld (ai_hint), neues Modul (ai/). Alles opt-in. App läuft ohne Ollama.

🚧

Plattformadapter isolieren

Alles Plattformspezifische liegt in tracker/platform/. Ein __init__.py wählt zur Laufzeit. Kein #if darwin außerhalb. Das macht Tests und neue Plattformen (Windows) einfach.


⭐ Open Source

Fork it. Bau darauf auf.

Das Repo ist offen. Nutze es als Vorlage, als Inspiration oder als Basis für deinen eigenen Zeiterfassungs-Klon — mit deinen eigenen 5 Agenten.