This document outlines the architectural and development principles for contributors to the plugin_loopstructural QGIS plugin. The plugin provides a thin, modular interface to the map2loop and LoopStructural libraries, enabling geological modeling workflows within QGIS.
- The plugin must not reimplement or duplicate functionality from
map2looporLoopStructural. - All core logic and enhancements should be contributed upstream to the respective libraries.
- The plugin should focus on UI integration, data flow orchestration, and user interaction.
- UI components (dialogs, panels, actions) live under the
loopstructural/gui/package and should be encapsulated in their own classes. - Business logic and orchestration are located in
loopstructural/main/andloopstructural/toolbelt/where adapters and services wrap external libraries. - Processing algorithms and QGIS provider integration are in
loopstructural/processing/and should be isolated from UI code. - Avoid tight coupling between components. Use signals/slots or event-driven patterns where appropriate.
- Use classes with clear responsibilities and interfaces.
- Prefer composition over inheritance unless subclassing is semantically appropriate.
- Encapsulate interactions with external libraries in dedicated adapter or service classes (e.g.,
loopstructural.main.Map2LoopService,loopstructural.main.LoopStructuralRunner).
- All code must pass the repository's pre-commit checks (formatting, linting, import sorting).
- Use type hints and docstrings for all public methods and classes.
- Follow PEP8 and QGIS plugin development best practices.
- All new code must include unit tests and, where applicable, integration tests.
- Tests live under the
tests/package and are runnable withpytest. - Mock external dependencies (
map2loop,LoopStructural) in unit tests.
plugin_loopstructural/
βββ loopstructural/ # plugin package
β βββ __init__.py
β βββ __about__.py
β βββ plugin_main.py # QGIS plugin entry and bootstrap
β βββ gui/ # UI dialogs, widgets, and panels
β βββ main/ # controllers, managers, adapters (service layer)
β βββ processing/ # QGIS processing provider and algorithms
β βββ toolbelt/ # utilities, env parsing, preferences, logging
β βββ resources/ # icons, translations, help files
β βββ requirements.txt
βββ docs/
βββ requirements/
βββ tests/
βββ README.md
Notes on mapping older concepts:
- What used to be called
services/andcontrollers/is implemented acrossloopstructural/main/andloopstructural/toolbelt/. - UI remains in
loopstructural/gui/(dialogs,.uifiles, widget classes). - Processing-specific code and QGIS provider live under
loopstructural/processing/.
- Fork the repository and create a feature branch.
- Implement changes following the design and code quality guidelines.
- Add or update tests under
tests/and ensure they run withpytest. - Run pre-commit hooks (e.g.
pre-commit run --all-files) and ensure all checks pass. - Submit a pull request with a clear description of the changes and rationale. Link to upstream libraries if behavior is moved upstream.
- Support for asynchronous or background processing of long-running tasks (consider using QGIS background task framework).
- Improved error handling and user feedback.
- Internationalization (i18n) support and keeping
.ts/.qm translation files inloopstructural/resources/i18n/. - Better separation of concerns between UI, processing algorithms and adapters to facilitate unit testing.
For questions or contributions to the upstream libraries:
map2loopLoopStructural