Replies: 2 comments
-
Here is the repo btw: https://gitlab.com/ubports/core/qtmir Please use the version on gitlab as reference as thats the latest and the version thats going into distros. |
Beta Was this translation helpful? Give feedback.
-
Yes, this situation was anticipated and discussed with the UBports team including you. It was even publicly announced: Mir 2.0.0 Release. There are currently features missing from miral that are used by qtmir, the way they were exposed and consumed by mirserver and qtmir isn't part of our strategic direction, but the fact the features were used indicates they should be useful and they will (or something better) be exposed in the 2.x series of releases. But we are, like you, a small team and we are not there yet.
As discussed previously, things that make sense to backport to 1.x can be backported to 1.x and we're willing to help with a 1.8.1 or 1.9.0 release. So far two fixes have been discussed (with @UniversalSuperBox and you):
I believe it to be possible to package Mir 1.x and Mir 2.x so that they can be co-installed, so having one in a distro should not preclude having the other. If there's a problem with that, we'll fix it.
Did the branches I was working on to "miral-ize" qtmir in 2016-2017 get merged? That would be a starting point as it localized the mirserver dependencies in a few files. Moving those to miral proper would be the way forward. |
Beta Was this translation helpful? Give feedback.
-
We over at ubports struggles to follow the development due to the removal of mirserver, with this we need to port qtmir to just miral in addition to this we also would need to add extra miral things (as its still lacking afaik), and with limited time hit an issue where we we will be stuck with 1.x. With this i'm wondering if the mir team would be able to help getting this up to speed with 2.x by maybe adding the lacking functions to miral and/or give some inside of whats needed for us to port it.
We are in progress of getting qtmir into debian, manjaro, postmaktedOS, fedora and others and this would ether mean mir would be stuck at mir 1.x in those distors (case for debian, manjaro and postmaktedOS) or we cant get into the archive (like with fedora). As lomiri is the driver to get mir in to the distors (except for fedora) this would mean we will be be using 1.x. and that lomiri currently is the only desktop environment using mir in production it would be nice for us to follow the development of mir to get the latest releases.
Also with getting lomiri into more distors, this would mean a more heavy focus on desktop users, this is where following mir really shines as we are still having many wayland and xwayland issues with 1.x that is fixed on 2.x. This will also hopefully get a more wide usage of mir across distors.
Thanks :)
Beta Was this translation helpful? Give feedback.
All reactions