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

[Julien Cabieces]

Hi David,

Thank you for taking the time to answer this.

> Hi all,
>
> On 11/4/25 09:22, Julien Cabieces via QGIS-Developer wrote:
>> 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
>
> I don't have an opinion on dirtying (due to lack of experience with
> it), but I do have an opinion on signals and callbacks:
>
> I agree that QGIS sometimes overuses signals, but I think callbacks
> are only a reasonable replacement where there will be exactly one
> callback, and only when that callback isn't stored in an object.
>

Why could we not have several callbacks ? And I'm not sure to really
understand what you mean when you say "that callback isn't stored in an
object".

> Apart from the code duplication introduced by manually handling lists
> of callback functions (and slowly reimplementing signals ourselves),
> signals, when attached to objects, will automatically respond to the
> destruction of one of the endpoints. This means that
> properly-connected signals will never cause use-after-free issues, and
> that is reason enough to use them, in my opinion.
>

signals/slots are way much than just simple callbacks as I described it
in my previous email. They can use event loop and deal with inter thread
communication for instance. So my proposal is IMHO far from reimplementing
signals ourselves.

Regarding use-after-free, indeed, the callee need to remove itself from
the callback list on destruction, like all the ressources it manages.

And code duplication could be avoided by putting the callback logic in some
class to extend

Regards,
Julien




> David Koňařík
> _______________________________________________
> 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