*First* priority

[AlanGriffiths]

To be successful Yunit needs to be something people can try and tinker with.

That means there ought to be an obvious way to install and experiment with Yunit without breaking the users system.

At present it is possible to download and experiment with the upstream Unity8 by installing unity8-desktop-session on Ubuntu 17.04. It is even possible to update this to the latest version of Mir (from the Mir release PPA) without risking system instability.

While it is possible to install Yunit on Ubuntu 16.04LTS it cannot be recommended for the casual user as that as that attempts to replaces the native Qt packages with more recent ones. This can cause problems that take expertise (or a re-install) to resolve.

Ubuntu 17.10 still carries the Mesa patches needed for Yunit to work and has dropped the Unity8 related packages, so these would not conflict with a Yunit PPA.

I think a Yunit PPA for Ubuntu 17.10 (and, eventually, 18.04LTS) would be a great way to promote this project.

[MggMuggins]

I would also recommend an AUR PKGBUILD, for those users on Arch or Arch-based distros. I realize that the dependency tree is large, but getting an AUR package available would definitely promote Yunit among the arch community.

[mthw0]

I agree with post above, PKGBUILD would be really nice.

[mauricioduarte01]

Amazing thread Alan! Your work for the community with Mir and other stuff are just brilliant. I just hope that Yunit Dev team will find some free time to continue with the project in the future.

Thank you all.

[AlanGriffiths]

I would also recommend an AUR PKGBUILD, for those users on Arch or Arch-based distros. I realize that the dependency tree is large, but getting an AUR package available would definitely promote Yunit among the arch community.

The reason I suggest Ubuntu 17.10 is that it carries the Mesa patch for Mir EGL.

In the future, it should be possible for Yunit to use Wayland's EGL in place of Mir's EGL. That would be a viable cross-distro stack but it needs work on Yunit and that first needs a platform that works "well enough". However, Mir's window management support for Wayland isn't yet at a point where Yunit could make the migration to Wayland.

The timeline might be:

1. Yunit PPA on Ubuntu 17.10
2. Mir support for Wayland improves
3. Yunit as an Ubuntu 18.04LTS "Flavour"
4. Yunit migrates to Wayland
5. Yunit becomes cross-distro

[jsalatas]

I believe that some people have discussed about porting in arch in past.

To add to Alan's comment, in addition to the Mesa patch for Mir EGL there is also the XMir patch for the x.org serve\r. Not sure if we need it after migrating to wayland :\

[jsalatas]

I just hope that Yunit Dev team will find some free time to continue with the project in the future.

Sorry about the delay, I'm working on it but really slow lately: I'm currently stuck with the oxide-qt engine and the gcc 7 which it's huge size proved to be a pain in the ass.

I tried to port the existing code to gcc7 and I managed to have it compiled, but almost every test fails and I'm still trying to figure how to update the chromium engine to a newer version. It seems that chromium's code is somehow patched before it ends into oxide-qt so it's not just merging with chromium's upstream repo.

Does any one know if there any additional documentation about oxide-qt apart from the following two links?

https://wiki.ubuntu.com/Oxide/BuildInstructions
https://wiki.ubuntu.com/Oxide/GetTheCode

[AlanGriffiths]

I believe that some people have discussed about porting in arch in past.

To add to Alan's comment, in addition to the Mesa patch for Mir EGL there is also the XMir patch for the x.org serve\r. Not sure if we need it after migrating to wayland :\

Yunit can work (for some value of "work") without Xmir. It is only needed for apps & toolkits without native support for Mir (e.g., with qtubuntu Qt applications can work with Mir).

Having said that, gtk & SDL do need Mir support enabled at build time as, unlike Qt they don't dynamically load the backend. And this is only case on Ubuntu.

So, yes, this is another reason for using Ubuntu as a starting point. It is the shortest path to something that works.

A subsequent step would be integrating the latest Mir and enabling Wayland. This is important too:

• gtk and SDL are likely to have been built with Wayland backends enabled. So, enabling Wayland is the way to provide a cross-disto solution.
• Wayland comes with an X11 server for applications that need one: Xwayland. It is very much like Xmir except that it runs on a Wayland server (in the case of Yunit this would be Mir).

[AlanGriffiths]

Sorry about the delay, I'm working on it but really slow lately: I'm currently stuck with the oxide-qt engine and the gcc 7 which it's huge size proved to be a pain in the ass.

I've not followed closely, so I may have this wrong: didn't UBports switch to a less "pain in the ass" rendering engine? Could that be a better way forwards?

[AlanGriffiths]

Sorry about the delay, I'm working on it but really slow lately: I'm currently stuck with the oxide-qt engine and the gcc 7 which it's huge size proved to be a pain in the ass.

I've not followed closely, so I may have this wrong: didn't UBports switch to a less "pain in the ass" rendering engine? Could that be a better way forwards?

Regardless of the accuracy of that suggestion, the advice from former Unity8 developers is that "keeping oxide alive is a insane task" for you, and that "oxide and qtwebengine have pretty similar APIs".

HTH