Build from source

[jwillikers]

Fixes element-hq/element-web#167

I'm working on building Element from source to allow using it on aarch64.

Tasks

• Build node-keytar from source.
• Build matrix-seshat from source.
• Is it possible to patch Element's hak scripts to make packaging these native dependencies work?

[flathubbot]

Started test build 56205

[flathubbot]

Build 56205 failed

[flathubbot]

Started test build 56206

[flathubbot]

Build 56206 failed

[flathubbot]

Started test build 56209

[flathubbot]

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

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

[flathubbot]

Started test build 56212

[flathubbot]

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

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

[vchernin]

In regard to 5316ba7:

The title bar is rendered as part of the window decorations for Electron. On X11 or xwayland (not using the ozone flags) you should have no problem.

However, the problem arises when you are using the Ozone flags (running Electron in Wayland natively):

Currently on GNOME Wayland you will not have window decorations when running Element in Wayland natively (as you've noticed). This is as GNOME Wayland requires applications to have client side decorations (CSD), in other words for the client to render the window decorations itself. The issue is Electron does not yet support CSD on Wayland. However, KDE Wayland and Sway support server side decorations (SSD) which renders window decorations on behalf of clients on the compositor side (i.e. without CSD).

So the issue you've encountered will only occur on GNOME Wayland when running Electron apps with the Ozone flags.

Luckily CSD for Electron is being worked on: electron/electron#29618, which will properly solve this issue for GNOME.

If enabling the Wayland socket by default means also passing the Ozone flags by default, we indeed probably don't want to do that for now. I wonder if there's a way of doing a check for GNOME or not though.

And btw thank you for working on this! I think building from source, and reducing the dependency on the DEB file is an important step for Element Flatpak (hopefully) becoming an official build someday (I'm just hoping).

[jwillikers]

@vchernin Thanks for that info, I wasn't aware of what all was going on with the CSD in Wayland / Electron there. I've pretty much got no clue what I'm doing when it comes to Javascript / Electron stuff, so any info is helpful. It appears that $DESKTOP_SESSION is available from inside the Flatpak, so I think I can just check if that's gnome and default accordingly.

I'd love to get this working, but I am concerned about the maintenance overhead of doing it this way. Most of it is pretty straightforward, but those two hak dependencies that Element manages using their own tooling might be a good chunk of work. Of course, any help is definitely appreciated, and thanks again!

[flathubbot]

Started test build 56543

[flathubbot]

Build 56543 failed

[flathubbot]

Started test build 56544

[flathubbot]

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

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

[vchernin]

Also, you might have missed it but there was a PR opened against your repo: jwillikers#1

[jwillikers]

@vchernin Thanks, I totally did miss that. Sorry about that @gasinvein, I've got that merged in!

[flathubbot]

Started test build 56642

[flathubbot]

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

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

[vchernin]

I wonder, since this is such a big change, is it a good idea to include Element’s renaming in this?

I mean that this PR could be submitted to become a new app io.element.Element, and then once that’s done im.riot.Riot can be EOLd (and users would be told to migrate to the new one).

[gasinvein]

This change isn't yet going anywhere without the native modules. Personally I still don't have any idea how to deal with Element's custom native modules downloader/builder.

[yajo]

element-hq/element-desktop#648 says that maybe building from source could fix the local-index-search-killing-element problem in the flatpak. Is there any progress in this PR?

[jwillikers]

Hi @yajo, this has stalled due to some issues related to how Element is built. In particular, it does some homebrew building around some particular dependencies that makes it very difficult to adhere to the Flatpak build model where all sources are cached in one phase and everything is built in the next. Last I checked, this appeared like it would require a decent amount of work upstream to make something like this work well. There's also element-hq/element-desktop#293, which is an attempt to build the Flatpak upstream and publish it directly.

[SISheogorath]

I'll close this one for now.