Remove Qt dependency

[romangg]

Most of Wrapland is Qt-independent and it could become a pure C++ library. This way compositors written in C++ but not built around the Qt ecosystem can make use of it.

element	plan
CMake	keep or replace with meson
PImpl idiom	keep
Q_PROPERTY	drop
Qt containers	std containers
QSharedPointer	std::shared_ptr
QScopedPointer	std::unique_ptr
QPointer	std::unique_ptr (?)
QThread	std::thread
QEnum	drop
Qt5::Test	reimplement or other framework (which one?)
event system	reimplement or replace with minimal external lib (which one?)
QPoint, QRect,...	Mir library equivalents: https://gitlab.com/kwinft/wrapland/-/issues/1#note_326400710

The event system is probably the most difficult part. Most of the current infrastructure is built around events so some event system needs to be there. A compositor using Wrapland must in some way also be willing to use the event system that Wrapland chooses. The question is if there are minimal event systems that can be used reasonably well in basically any C++ project.

[romangg]

For the signals/slots i.e. event system: libsigc++ is C++17, actively used and developed and can be integrated with Qt. It looks really promising.

[romangg]

This is being pushed forward indirectly as part of #15, where the QT dependencies are pushed to the outer-most layer of our server API.

While working on that I realized that we could internally only use functors and in the exported API besides the functor-approach maybe provide compile-optional adaptors for the export of Qt objects and other types like the ones of libsigc++.

This way a compositor could be written either without any other dependencies or in Qt style or by leveraging other frameworks.

[romangg]

In GitLab by @StefanoD1 on Apr 17, 2020, 19:51

For geometry classes like QPoint, you can use these implementations:

https://github.com/MirServer/mir/tree/98eca8652d4bc75c79fe56cfc96bbea248d9de29/include/core/mir/geometry

[romangg]

Thanks! I added it to the table.

[romangg]

marked this issue as related to #34

[romangg]

Moving back to decide stage, since this is an overview task and some parts of it are not yet fully clear/decided.

[romangg]

For signals/slot see here for a benchmark between different implementations.

In general one could also think of using a minimal header-only implementation internally that then connects to different API-interfaces. Something like sigs or above Nuclex (yes, it's Subversion).

[romangg]

mentioned in issue disman#1

[romangg]

For testing Catch2 looks interesting: why-catch.md

[romangg]

Another interesting test framework is doctest. Also see discussion on reddit about its advantages over Catch2.

[romangg]

In GitLab by @aramgrigoryan on Aug 22, 2021, 19:56

Very interesting discussion here. I like the general idea and approaches. But a danger i see is that while trying to ditch Qt we will end up just replacing some headers without changing structure and the logic of the code itself. Sort of a mind trap, where we just mimic what was done same way with just other tools... Repeating what Qt enforced on us. So one question would be Does wrapland really need signal&slots mechanism AT ALL? Although the chosen library is good, but here we have a once in a time opportunity to look deeper. On the testing part yes, Catch2 is good, especially with its latest v3 release.

[romangg]

But a danger i see is that while trying to ditch Qt we will end up just replacing some headers without changing structure and the logic of the code itself. Sort of a mind trap, where we just mimic what was done same way with just other tools...

Well put. Yes, I agree one can tend to limit oneself here by not prospecting alternative ideas by just concentrating on replacing 1-to-1. On the other side it might be difficult to do both at once to the point where the whole process is put on hold through too much ambition and practical difficulties in the realization.

I would say it's worth it to look into improving logic in some selected areas but paces oneself in that.

So one question would be Does wrapland really need signal&slots mechanism AT ALL?

Yes, good question. It doesn't need it per se. Without having theoretical proof for it I would think everything a signal-slot library does can be done by simple callbacks too (that is setting function pointers like you would usually do in a C program).

The concept of signals and slots can simplify that sometimes, but from experience I can say it also comes with the risk of overusing it.

We can discuss this some more. We still have time before really moving forward with the replacement or alternatively removal of any signal-slot implementation.

On the testing part yes, Catch2 is good, especially with its latest v3 release.

You prefer v3 of Catch2 over doctest?

[romangg]

Another test and benchmark: Julien Jorge: Testing C++ signal-slot libraries

I'm particular interested in palacaze's Sigslot header-only library.

[romangg]

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

Hey there, I'm a tdesktop contributor. Shame on me, but I completely failed to understand how to work with libwayland thus tdesktop uses kwayland. It's used for things like xdg-decoration presence detection (to adjust available settings in the UI), xdg_exporter support for dbus portal dialogs ('Open With', file dialog, autostart permissions), the possibility to hide taskbar icon via PlasmaShell protocol and global menu support with the AppMenuManager protocol. tdesktop migrated to Qt 6 some time ago and forced to patch kwayland in order to build it with Qt 6 (well, only cmake files though). It would be nice to migrate to Wrapland if it won't use Qt, can I help somehow with that?

[romangg]

Hi Ilya, of course I know you from your work on tdesktop and in general by being an active member of the open source community. :)

Regarding your question, yes I think Wrapland could be a great fit for tdesktop, especially if we can get rid of Qt usage in it but still provide a convenient API for apps written with Qt.

There are two bigger stepping-stones for that at the moment. One is that right now we use Qt's signal and slots everywhere. Since you've already commented on #34 you're aware of that. Let's discuss the topic in #34 some more.

Another is that in the client library Wrapland makes use of Qt's event loop to interact with libwayland's asynchronous client interface. I haven't yet put thought into how this should be replaced. But if there is now with tdesktop a client that could use a Qt-free Wrapland client library, we can prioritize it. Do you have immediately an idea how that should look instead? How are you currently initializing KWayland's connection thread in tdesktop?

[romangg]

In GitLab by @ilya-fedin on Dec 11, 2021, 12:10

Do you have immediately an idea how that should look instead?

ConnectionThread runs in a separate thread, each thread has its own event loop (QThread launches it under the hood for you), so you can use any event loop library you want: application's main thread will use its own event loop, you will use your own event loop on your thread.

How are you currently initializing KWayland's connection thread in tdesktop?

ConnectionThread::fromApplication

[romangg]

In GitLab by @ilya-fedin on Dec 11, 2021, 12:27

Ah, QCoreApplication::eventDispatcher returns event loop of the main thread. IMHO, the most effective way is to create a method in the class that would call wl_display_flush and let users manually integrate it to theirs event loop (that's almost one line in Qt and shouldn't be harder with other toolkits (e.g. gtk's glib has so-called 'idle sources')

[romangg]

Another option since recently is KDBindings.

[romangg]

In GitLab by @ilya-fedin on Jun 20, 2022, 14:48

tdesktop also has its own reactive programming library: https://github.com/desktop-app/lib_rpl/
Its usage looks like

rpl::variable<std::string> text;
text.value() | rpl::start_with_next([](const std::string& value) {
  std::cout << value << std::endl;
});
text = "Hello World!";

[romangg]

mentioned in issue kwinft#317

[romangg]

The original maintainer of doctest left the project and it looks like activity has decreased. So Catch2 is a safer bet. Personally I already gained some experience with Catch2 since recently, so that's another argument for using it.