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