[QGIS-Developer] Dirtying project within model classes or not

[Nyall Dawson]

On Tue, 4 Nov 2025 at 02:45, Julien Cabieces via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:
>

> So, I'd like to know if we should:
> - always dirty the project within model classes
> - never dirty the project within model classes
> - it depends...

Thanks for raising this discussion Julien, I agree that a project-wide
policy/guideline would be better than the ad-hoc approach we currently
have. While I believe that conceptually dirtying a project IS an app level
operation, my strongest counter-argument against dirtying from core classes
is that not every class in core which "changes" a project HAS a way of
notifying that project that it's been dirtied.

For instance -- a layer's appearance can be changed via something like:

layer->renderer()->symbol().setColor(...)

There's NO way for symbols or renderers to notify the project (or even the
layer) of these changes. A QgsSymbol doesn't (and shouldn't) keep a
reference to its owner QgsFeatureRenderer, and the renderer doesn't keep a
reference to its owner QgsVectorLayer. Neither QgsSymbol or
QgsFeatureRenderer are QObjects (and they definitely should NOT be!!), so
we can't eg emit signals from the symbol to notify of changes. The only way
a change to one of these objects has to dirty a project would be a nasty
QgsProject::instance()->setDirty() call, and (for good reason!)
introduction of new occurrences of QgsProject::instance() is
explicitly prohibited in core code.

This leaves us in the situation where SOME calls to api methods in core
classes dirties the project, but others have no possible way to do that.
And this API inconsistency leads to a mess -- a caller would have no
predictable way of knowing if any particular API call which effectively
modifies a project will dirty the project or not, so they'll just need to
manually dirty the project anyway to be certain. Or in short: if we dirty
from core classes, we'll *always* have a need to *also* have dirty calls
from gui/app.

The alternative is to decide that dirtying belongs only at the app/gui
level, and this makes things nice and predictable -- if a GUI / user
operation changes the project, that gui/app code is responsible for
dirtying the project. No ambiguity involved 🥳

Nyall


>
> Regards,
> Julien
>
> [0] https://github.com/qgis/QGIS/pull/63498#discussion_r2425462712
> [1]
https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L490
> [2]
https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L975
>
> --
>
> Julien Cabieces
> Senior Developer at Oslandia
> julien.cabieces at oslandia.com
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20251104/349a6451/attachment.htm>