I would say push it also to master.

1. I don't mind having it directly in xdg-desktop-portal-kde, but if it's something that might be re-used, it might be better to put it into some framework.

2-3) Kirigami-addons will be probably my preference. It sounds like something that can be re-used so why not write it that way. Then in xdg-desktop-portal-kde we will just check if it's running on mobile and create a dialog based on that.

4. This might complicate it a bit, because you either would need to implement all the other portals which are same for both the desktop and mobile, or you would need to set different value to XDG_CURRENT_DESKTOP so xdg-desktop-portal first loads your portal implementation for some portals and then xdg-desktop-portal-kde as fallback for the rest.

I have tested this and it now works as before, tested with Chromium, while checking all the values we pass to the portal and PipeWire which seem to be correct.

I have tested this and it now works as before, tested with Chromium, while checking all the values we pass to the portal and PipeWire which seem to be correct.

Looks good and it works for me, tested with Chromium.

With all code relevant to PipeWire removed, you can remove all needed CMake find modules in cmake subdir and you can also remove the ENABLE_PIPEWIRE option as it shouldn't be needed anymore (including all ifdefs).

In D28882#653483, @jgrulich wrote:

Doesn't seem to build here:

In file included from /home/jgrulich/development/projects/kde/kwayland/src/server/screencasting_interface.cpp:7:
/home/jgrulich/development/projects/kde/kwayland/src/server/screencasting_interface.h:32:121: error: ‘std::function’ has not been declared
   32 |     ScreencastingSource(const QString &description, const QString &iconName, bool isOutput, const QRect &geometry, std::function<void(const ScreencastingSource &, wl_resource *)>);
      |                                                                                                                         ^~~~~~~~
In file included from /home/jgrulich/development/projects/kde/kwayland/src/server/screencasting_interface.cpp:7:
/home/jgrulich/development/projects/kde/kwayland/src/server/screencasting_interface.h:32:129: error: expected ‘,’ or ‘...’ before ‘<’ token
   32 |     ScreencastingSource(const QString &description, const QString &iconName, bool isOutput, const QRect &geometry, std::function<void(const ScreencastingSource &, wl_resource *)>);
      |                                                                                                                                 ^
/home/jgrulich/development/projects/kde/kwayland/src/server/screencasting_interface.cpp:41:1: error: no declaration matches ‘KWayland::Server::ScreencastingSource::ScreencastingSource(const QString&, const QString&, bool, const QRect&, std::function<void(const KWayland::Server::ScreencastingSource&, wl_resource*)>)’
   41 | ScreencastingSource::ScreencastingSource(const QString &description, const QString &iconName, bool isOutput, const QRect &geometry, std::function<void(const ScreencastingSource &,wl_resource *r)> call)
      | ^~~~~~~~~~~~~~~~~~~

Doesn't seem to build here:

I think we can drop support for PipeWire 0.2 (you don't seem to search for it anyway) so you can drop all PW_CHECK_VERSION(0, 2, 90) and keep just the branch for PipeWire 0.3. I will do some proper testing tomorrow.

I wanted to let @ngraham to review this UI wise, but I see there are no UI changes. I don't follow mobile KCM development so I'm not sure I'm the right person to review this, but it looks good to me. I haven't tried it, but I believe you.

Those were probably all issues I could find. I will keep using it and if I find something later, I will let you know. Thank you.

• Better naming for the cmake option disabling PipeWire

Make DISABLE_PIPEWIRE_SUPPORT a cmake option and remove a leftover from previous change

In D28698#644705, @davidedmundson wrote:

(the ugly notification which pops on the top of screen) when Plasma notifications are not ready yet

Plasma ships a trick for that which means that we always get plasma notifications when plasma is installed regardless of if it's running.

I see that we already initialize the secret agent right when the kded module is loaded, but I see a potential problem in showing a notification using a fallback backend (the ugly notification which pops on the top of screen) when Plasma notifications are not ready yet.

Actually it was me who pushed this, Lukáš just did some changes to it.

In D28698#644698, @nicolasfella wrote:

Yes, but I don't see this being a problem

In D28698#644695, @broulik wrote:

Isn't that Handler also used from the plasmoid and KCM, which is in a separate process from kded?

In D28677#644196, @davidedmundson wrote:

Also allow to completely disable Wayland support in case some distribution don't ship PipeWire yet.

I don't follow, why don't we just disable the screencasting thing if we don't have pipewire. I don't see why we would affect the rest.

Allow to disable only PipeWire, while keeping rest of Wayland support

I asked on kde-distribution-packagers, so far I got only response from Slack and the response was they don't care about Wayland, if they would, they would have included PipeWire. I think it should be either don't support Wayland at all if distribution doesn't care or support it fully and let them get PipeWire included.

In D28677#644196, @davidedmundson wrote:

Also allow to completely disable Wayland support in case some distribution don't ship PipeWire yet.

I don't follow, why don't we just disable the screencasting thing if we don't have pipewire. I don't see why we would affect the rest.

Looks good to me. @broulik what do you think?

In D28214#643478, @bcooksley wrote:

This change, as committed does not appear to compile:
https://build.kde.org/view/Failing/job/Plasma/job/xdg-desktop-portal-kde/job/kf5-qt5%20FreeBSDQt5.14/lastFailedBuild/console