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

[Julien Cabieces]

> 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.
>

Why not plain old callbacks instead of signals (I don't like that much
signals, It's hard to debug, I think we use them too much). QgsSymbol could have some
methods like this

void addModifiedCallback( std::function<void> callback )
{
  mCallbacks.append( callback );
}

void dirty()
{
  for( auto callback : mCallbacks )
     callback();
}

void setSize( double size )
{
  ...
  dirty();
}

And QgsFeatureRenderer would report it to QgsVectorLayer, which would
then report it to QgsProject


> 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 🥳
>

Plugin developer could forget to dirty. And according to murphy law, if
they could, they would! Doing it in core will prevent us from this


> 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

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com