Digital Log Book

Field service technicians have tracked parts usage the same way for decades, a paper logbook. It works, but it's slow, error prone, and makes pulling historical data for any given machine or part a genuine chore. The Digital Log Book is a desktop application built as a direct replacement for that workflow, designed specifically for the copier and printer service domain with manufacturers like Kyocera, Konica Minolta, Canon, HP, and Brother in mind. It exists because the paper alternative was frustrating enough to warrant building something better.

Current Focus

A significant architectural refactor is underway on a dedicated testing branch before the next release. The focus is on separating concerns into distinct modules, improving cross-platform reliability, and hardening the multiprocessing pipeline. Full menu traversal is error-free at this point, with button interaction testing currently in progress and the most complex menus saved for last.

Current State

The foundation decisions are made, stack selected, GUI layout drafted, and the core feature set defined. No implementation has begun yet, which is by design. The project is being built the right way from the start rather than the fast way.

What Works

The core application flow is stable and fully navigable. Settings management lives in a dedicated singleton module, database operations are separated into their own handler, and cross-platform path handling is managed consistently via pathlib. Progress tracking runs through a multiprocessing queue feeding GUI updates cleanly, and structured logging via a custom AppLogging package keeps exceptions visible across process boundaries, a detail that matters more than it might seem once multiprocessing enters the picture.

What's Planned

The immediate priority is completing testing on the two most complex remaining menus, the multiprocessing and OCR barcode pipeline menu, and the manual review menu which includes an in-app PDF viewer with JSON-driven field population. Once those pass, the refactored build gets released to master. Longer term, the application has room to grow in reporting and filtering capabilities as real-world usage patterns inform what is actually useful versus what only seemed useful on paper.

How It's Built

Python 3.x with CustomTkinter handling the desktop interface and SQLite as the backing database. Multiprocessing handles the heavier pipeline work, with a queue-based architecture keeping the GUI responsive during long operations. Cross-platform path handling via pathlib and a custom AppLogging package rounding out the stack. Packaged via pyproject.toml for clean installation and distribution.