Started test build 44866

The Wayland and Pipewire support is based on flathub/org.jitsi.jitsi-meet@63f9a41 and flathub/org.jitsi.jitsi-meet@00e7deb.

Build 44866 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/43160/im.riot.Riot.flatpakref

This isn't working quite yet. The 1.7.25 deb is missing, waiting on that to appear before I bump the version itself. Package has been made available by upstream now.

I this case we have to make sure we don't force Wayland usage using the parameters, as well as we should change the permission form x11 to fallback-x11 which will restrict x11 access to systems with no Wayland available.

Started test build 44871

I this case we have to make sure we don't force Wayland usage using the parameters, as well as we should change the permission form x11 to fallback-x11 which will restrict x11 access to systems with no Wayland available.

I don't believe this forces Wayland usage in any way. It just makes it possible to run it with the Wayland backend if you pass the necessary parameters. I don't believe Ozone is yet in a state where it should automatically be turned on when a Wayland session is detected (and Chromium doesn't do so). Element itself doesn't start up by default with the Ozone or Pipewire backends either.

This PR does just enough that you can now do flatpak run im.riot.Riot --enable-features=UseOzonePlatform,WebRTCPipeWireCapturer --ozone-platform=wayland to try things for yourself.

Build 44871 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/43165/im.riot.Riot.flatpakref

I don't know if it might be preferable to have some kind of env var, like FLATPAK_ELEMENT_USE_WAYLAND that would in turn pass the --enable-features=UseOzonePlatform,WebRTCPipeWireCapturer --ozone-platform=wayland? I'm not really sure how this is normally done for Flatpak.

Sort of related, Electron doesn't yet have client side decorations, electron/electron#27522, so until then it should probably not enable Wayland by default even if on a Wayland session. I think it's expected to work fine for Wayland sessions that do have SSDs though, so realistically it's mostly wonky under Gnome/Mutter and would work fine on KDE or Sway.

If it doesn't work properly and is currently more of an optional/beta feature, I don't think we should push it yet into our stable steam. Therefore, I would leave the PR around, but not merge it until things are stabilised on electron side.

If the feature is already hidden behind runtime switches then why hide it even more in flatpak? For users who want the feature it will be easier to enable and the rest won't see any change.

If it doesn't work properly and is currently more of an optional/beta feature, I don't think we should push it yet into our stable steam. Therefore, I would leave the PR around, but not merge it until things are stabilised on electron side.

In my own experience, it works entirely fine. It's stable under the Wayland session, and I haven't had any issues. The only oddity is CSD, but since I'm used to using keyboard shortcuts to resize my windows in Gnome that's personally not been a problem.

Given it's not enabled by default and it just lets people experiment with it through flatpak run it doesn't seem like it would harm anyone. Just having the PR up doesn't seem super handy, since you still need to rebuild (to include libpipewire) and the build attached to this PR will be outdated in 2 weeks from now when the next Element release comes out.

I have to apologies here, somehow, due to mainly reading this whole thing on the phone, I missed that this PR doesn't provide the parameters in the default script. In this case, I would rather disable the wayland permission, since it's not used, but include the required ground work to have people experimenting :)

wayland permission is safe to have and needed to test the feature.

I suppose that's possible. The nice thing about the current state is that you only need to care about the Electron parameters, and won't have to figure out you also need --socket=wayland using either flatpak run or flatpak override.

Is there any way we can document this to at least make this fact somewhat discoverable for people?

I suppose we could add it to the description, but otherwise, no, we have no further place for documentation.

Started test build 44964

Alright, I've removed the socket from the defaults and added a paragraph in the description.

Build 44964 failed

Started test build 44965

Build 44964 failed

Looks like I'm not allowed to break up a paragraph over multiple lines.

Build 44965 failed

Huh. I'm not allowed to have multiple paragraphs? Or is it mad about the code thing?

It's supposed to be fine

Within paragraphs and list items, emphasis (em) and inline code (code) text styles are supported. The emphasis is commonly rendered in italic, while inline code is shown in a monospaced font.

https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-description

Started test build 44966

According to https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html#tag-ct-description, only <p>, <ul>, and <li> are allowed so it probably won't allow any other (unescaped) tags.

Build 44966 failed

According to https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html#tag-ct-description, only <p>, <ul>, and <li> are allowed so it probably won't allow any other (unescaped) tags.

Yeah, it says that. But if you then click through to the description tag, it says it supports code too... I tried a build without the code block and it still exploded.

The PR is set up to allow edit from maintainers, so if someone knows what the problem with the description thing is go ahead and tack on a commit. I'm a bit lost. The feedback from the build isn't very enlightening unfortunately.

I think appstore metadata is supposed to be platform agnostic and generally non-technical. Such detailed flatpak info may belong in github readme.

I think appstore metadata is supposed to be platform agnostic and generally non-technical. Such detailed flatpak info may belong in github readme.

The README of this repository is not easily reached from within a store like Gnome Software or KDE Discover. If we're going to go and put people through that kind of an experience I'd rather drop this PR entirely because it doesn't seem likely anyone would ever find it.

Started test build 44984

Build 44984 failed

Started test build 44988

Build 44988 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/43280/im.riot.Riot.flatpakref

Running this on Arch Linux in a Wayland session does not work for me. If I just run the test branch with flatpak run im.riot.Riot//test, it runs but it's blurry as expected.

The only thing that it says in the terminal for me is Modifiers specified, but DRI is too old which doesn't seem relevant. The tray icon still appears and is usable, though.

@daenney this is why I argue to just add wayland permission and be done with this. This is the best experience for all users.

Chromium has this permission so why riot can't?

Running this on Arch Linux in a Wayland session does not work for me. If I just run the test branch with flatpak run im.riot.Riot//test, it runs but it's blurry as expected.

The only thing that it says in the terminal for me is Modifiers specified, but DRI is too old which doesn't seem relevant. The tray icon still appears and is usable, though.

This works perfectly for me:

flatpak run --socket=wayland im.riot.Riot//test --enable-features=UseOzonePlatform,WebRTCPipeWireCapturer --ozone-platform=wayland

I'll leave it for the maintainers to decide what to do about the --socket=wayland. This has taken more time than I'd like for something I would have imagined isn't all that contentious.

If someone with the ability to merge this can tell me how they'd like to move forward, I'm happy to adjust the PR accordingly.

Running this on Arch Linux in a Wayland session does not work for me. If I just run the test branch with flatpak run im.riot.Riot//test, it runs but it's blurry as expected.
The only thing that it says in the terminal for me is Modifiers specified, but DRI is too old which doesn't seem relevant. The tray icon still appears and is usable, though.

This works perfectly for me:

flatpak run --socket=wayland im.riot.Riot//test --enable-features=UseOzonePlatform,WebRTCPipeWireCapturer --ozone-platform=wayland

It works on my Tumbleweed install! So it's just something broken on the Arch install. The fonts seem to have no anti-aliasing compared to the rest of my DE, though.

Thank you very much, you convinced me, that my reaction towards the permissions was probably a bit over concerned. It's merged, we are going for it! Thanks a lot! :)

@shegorath after adding wayland permission the appdata description isn't accurate anymore, perhaps there shouldn't be any description at all as those aren't riot specific instructions but generic electron/chromium experimental flags.

Yeah, okay, the --socket=Wayland is no longer required now, but it doesn't make it incorrect. It'll function. If we get complaints about something not working, we can consider to drop it. For now, I would wait and see what happens.

@SISheogorath the descripton seems broken on flathub site when visiting from ff, the whole code block isn't shown only To try running Element natively under Wayland, run: without commands.

Oh, interesting. I guess I should open a bug report for the frontend, since it's supported in the spec.

And some little bit of research forward: flathub-infra/linux-store-frontend#203 There we are, seeing it's broken for both <em> and <code> tags. But a "solution" was provided by manjaro during Christmas but didn't make it upstream apparently: guinux/appstream-glib@7fef9b4

So I guess, we have to get rid of those descriptions as neither flathub nor GNOME software is able to read them even though they are standard conform. 😬