libsigc++ replacing Qt signals/slots

[romangg]

Wrapland uses the concept of signals and slots heavily. While in general I try to limit its usage we still need it in certain places. libsigc++ is a promising alternative to the Qt implementation that makes use of modern C++.

Decision

Upstream project health

• Is used by gtkmm, which is a Gnome project.
• Has two maintainers. Both active in Gnome.
• But last commit to libsigc++ over half a month ago (maybe it's in a stable state and there is not much to do at the moment).
• And there is one open ticket for the same period without any replies.
• Their CI is failing because of that for the same period.

Integration with Qt

This is necessary because we need to make use of the Client library in KWinFT and libkscreen. Apparently that is possible.

Alternative: functors internally and signal/slot API mask

An alternative idea would be to divide Wrapland into two parts: an internal part where we only use functor objects (callbacks) instead of signals/slots. And provide certain API "masks" with different kinds of signals/slots mechanisms so consumers can opt-in to which one they want to use.

That way we wouldn't need any explicit integration between libsigc++ and Qt and we wouldn't need libsigc++ to compile with the Qt API mask.

Implementation

Server library

Currently the server-objects project has priority. Changes to the signal/slot-system can only commence afterwards.

Client library

Consumers to consider

• KWinFT (internally for certain functionality and autotests)
• libkscreen (with Wrapland support)

Plan

TODO

Prototypes

Merge request !13

[romangg]

marked this issue as related to #1

[romangg]

I believe we should first finish a first iteration of the server remodel.

We will continue to use Qt signals/slots with that and afterwards we can check out libsigc++. The server-side will then be nicely unraveled into two or more layers allowing us to implement it on one of them.

[romangg]

In GitLab by @ilya-fedin on Dec 11, 2021, 03:19

IMHO, it's worth to look at https://github.com/ReactiveX/RxCpp
It seems to be more active

[romangg]

look at https://github.com/ReactiveX/RxCpp

That's very interesting indeed. I haven't worked with ReactiveX in the past so I read up on it some more first.

I like that it's a big project with a universal approach and different language bindings. From what I read though and how I imagine it to be (somewhat like QML bindings updating model data automatically?) I'm unsure if it's the right fit for the libwayland-wrapping Wrapland library.

As described in the excellent documentation the framework is especially useful for UI components. But Wrapland itself is rather a backend component. Making heavy use of Qt in it was a similar domain violation in my opinion. On the other side ReactiveX can also be useful for asynchronous operations. And while Wrapland does not require to provide asynchronous means in its server library (the part compositors link to), it does so in the client library (the part tdesktop would link to). So it could still be a good idea to just in general make use of the ReactiveX framework.

I missed to note it here but since I created this ticket I actually moved away from the idea of using libsigc++ somewhat and I was rather looking at Palacaze's small foot-print, single-header sigslot library. I believe it's all what we need for our internal usage of the observer pattern and I like its minimalistic approach. On the other side it's not a big project like ReactiveX and does not have a lot or any corporate backing.

I don't yet fully understand ReactiveX so it would be interesting to know if its universal approach could benefit us also in other ways than simply as a Qt signals/slots replacement.