Files

T

austinandClaude Opus 5 260704cf9b Add --db and let the user choose where the database lives

- `kareer --db <path>` works for the GUI and every subcommand, before
  or after the subcommand name, and creates the file if missing. main()
  strips it from argv before CLI/GUI routing; every parser declares it
  so it shows in --help.
- Path precedence: --db > KAREER_DB_PATH > the location chosen in the
  GUI (kareerrc [Database] Path, read at startup for GUI and CLI alike)
  > $XDG_DATA_HOME/kareer/kareer.sqlite.
- First GUI run (nothing forced, no file yet, or the configured file
  has gone missing): DatabaseSetupDialog offers the default location, a
  folder of the user's choice, or an existing database used in place.
  Until then JobsDatabase opens nothing.
- Preferences gains a Database section: Move to... (copies, leaves the
  original), Open Existing..., Use Default Location. Refuses foreign
  SQLite files and unwritable ones.
- Models call JobsDatabase::reopenIfPathChanged() on refresh, so
  switching databases needs no restart.
- Link KF6::ConfigCore; add a QuickDialogs2 configure-time guard; add
  kconfig to the Arch dependencies and a note to the Flatpak manifest.
- README documents --db, the precedence, and the first-run choice, and
  gains Fedora 44 build dependencies; CONTRIBUTING gets a dev recipe.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01BxDf7HqD1xPnsZP8wt3NTk

2026-09-11 15:42:00 -05:00

2.2 KiB

Raw Blame History

Contributing to Kareer

Build

Kareer is a KDE/Kirigami application (C++20 + QML) built with CMake and Extra CMake Modules. See the README for the full list of system packages to install, then:

cmake -B build -G Ninja
cmake --build build
./build/bin/kareer

To develop against a throwaway database instead of your real one, pass --db (the file is created if it doesn't exist); it works for the GUI and every subcommand:

./build/bin/kareer --db build/dev.sqlite add --company Acme --title Engineer
./build/bin/kareer --db build/dev.sqlite

To see the first-run "where should the database live?" dialog, start with empty config and data directories:

XDG_CONFIG_HOME=$(mktemp -d) XDG_DATA_HOME=$(mktemp -d) ./build/bin/kareer

Test

ctest --test-dir build --output-on-failure

Tests live in autotests/ and link the core logic directly out of src/ (see autotests/CMakeLists.txt). CI runs the same suite on every pull request via .github/workflows/test.yml, using flatpak-builder's run-tests option so the run happens inside the same KDE SDK sandbox as release builds.

Conventions

Every source file starts with SPDX-License-Identifier: GPL-3.0-or-later (in whatever comment syntax fits the file type). Files that can't carry an inline header — .desktop, keys/*.asc — are covered instead by REUSE.toml.

src/ is intentionally flat: one class per concern, no models/, controllers/, or viewmodels/ subfolders.
C++ backend classes are exposed to QML via QML_ELEMENT; QML views are meant to stay thin renderers over that state, not hold logic themselves.
JobsDatabase is the only class that touches the SQLite database directly — route all persistence changes through it.

Releasing

.github/workflows/build.yml builds, signs, and publishes a Flatpak bundle whenever a v* tag is pushed. To cut a release: bump project(... VERSION ...) in CMakeLists.txt, add a matching <release> entry to the metainfo file, update the manifest's pinned tag:, then tag and push.