@arubislander said in Saturday Is Q&A Day! Q&A 32 Saturday 14/07 19:00 UTC:

While I understand what you are saying I disagree with your proposal. Moving to 18.04 might be a bigger task than moving to 16.04, because in 16.04 Touch was still being supported and Canonical had already done at least some preliminary work.

My question was intended for the devs, and I didn’t mean to start a debate among us users. But I appreciate your reply. What’s more, your reply demonstrates that I may not have sufficiently articulated my thoughts.

You are, absolutely and without question, correct that moving to 18.04 will be a much bigger task than moving to 16.04. That said, provided a few puzzle pieces fall into place (and it looks like some of them are starting to fall into place), moving to 18.04 may go faster than you expect.

To clarify, I fully support completing 16.04 OTA-4, and I fully support completing 16.04 OTA-5. However, with regard to what would be “good enough” for 16.04 OTA-5, my thinking is that, provided some puzzle pieces fall into place for 18.04, the devs should focus on the “bugs” listed in the milestones for 16.04 OTA-5 and leave the “enhancements” listed there for a hopefully soon-to-be started 18.04 OTA-6 or 18.04 OTA-7. Of course, what’s “good enough” may need to be reevaluated from time to time.

As for skipping 18.04, and waiting for 20.04, in my opinion, that would be a very bad idea. But your question seems intended for the devs, so I’ll let the devs to respond to your question.

I realize that the UBports team is currently focusing on 16.04 OTA-4, and that plans for 16.04 OTA-5 are still evolving. Nonetheless, looking at the milestones page, I can’t help but notice that many “enhancements” are currently being considered for 16.04 OTA-5.

My thinking is that 16.04, although 100% necessary, only needs to be “good enough” to serve as a reliable stopgap, and that development should start focusing on 18.04 as soon as practical.

Question: Provided some puzzle pieces fall into place for 18.04, would you consider restricting 16.04 OTA-5 to bug fixes (with few or none of the "enhancements" currently listed in the 16.04 OTA-5 milestones page), so that you can begin focusing more fully on 18.04 development?

Edit: After considering a reply from @arubislander to my comment, I have italicized the phrase "provided some puzzle pieces fall into place for 18.04" found in my original question, to add emphasis. Also, I have clarified that the term "enhancements" refers to the "enhancements" currently listed in the 16.04 OTA-5 milestones page. Please see my comment found here for additional clarification.

@alan_g said in 18.04 desktop - getting it working again:

I found one problem, which I fixed by hacking the launch script

Just to be sure we're seeing the same problem (which we probably are), I still posted my results in in the PR.

I'm not sure how either problem was avoided before.

Note that, in addition to posting results for Mir 0.32.1 RC4 (installed from ppa:mir-team/rc), I also posted results for Mir 0.32.0 (installed from the UBports repo). Hope that helps.

@alan_g said in 18.04 desktop - getting it working again:

We need to understand what is happening, could you leave a message on the 0.32.1 PR? Preferably with informative log messages?

I posted in this PR for Mir release 0.32.1. I mostly just reiterated what I posted here, but I did add a few minor details regarding my system.

As for posting informative log messages, I’m not sure what to look for, or even where to look. With some guidance, I’d be happy to try. But realistically, the quicker approach would probably be for someone else to confirm what I’m reporting.

Perhaps someone who is also testing Unity8, but who is more technically savvy than me, would be willing to test Unity8 installed as described here along with a Mir 0.32.1 RC installed from ppa:mir-team/rc? Do you know of anyone who fits that description, @pixelr0? :)

After installing Unity8 using the instructions found here, I was able to log into Unity8 from either GDM or LightDM.

I upgraded from Mir 0.32 to Mir 0.32.1 RC4 via ppa:mir-team/rc, and now, I can no longer log into Unity8 from either GDM or LightDM. What’s more, when I merely attempt to log into Unity8 with Mir 0.32.1 RC4 installed, I must reboot my system before I am again able to log into GNOME or Unity7.

@mariogrip and/or @alan_g: Is Unity8 currently installing a modified version of Mir 0.32 rather than upstream Mir 0.32?

If Unity8 is installing a modified version of Mir 0.32, then I would expect Mir 0.32.1 RCs likely not to work, and I’ll stop attempting to test the Mir 0.32.1 RCs for now.

@alan_g: If Unity8 is installing upstream Mir 0.32, shouldn’t the Mir 0.32.1 RCs from ppa:mir-team/rc be expected to work with Unity8? Or am I missing a step?

For the adventurous it would be reasonable to take Ubuntu 18.04 and...

1. install the Mir from the Release Candidate PPA and Unity8 from UBports;
2. recompile and install QtMir locally; and,
3. try logging into a Unity8 desktop session.

Reportedly, the UBports repo has been updated, and Unity8 can again be installed using the instructions found here.

Unity8 on 18.04 is discussed in Ubuntu Touch Q&A 31 starting at about 61m49s.

@gizmochicken said in Its That Time Again! Q&A 31 This Saturday.:

Have you tested Unity8 on 18.04 with Mir 0.32? Impressions?

Marius discussing Unity8 on 18.04: "It's awesome!"

Have you tested Unity8 on 18.04 with Mir 0.32? Impressions?

Also, if familiar with the situation, would you please discuss what necessitated the "recompile and install QtMir locally" step that alan_g recommends in a recent post related to installing Unity8 on 18.04?

(Note that the "recompile and install QtMir locally" step isn't mentioned in the previous installation instructions.)

@alan_g said in Reverse Convergence? View & control your phone from computer (like VNC & RDP?):

the team at Canonical are obliged to prioritise their efforts

Thanks much for the reply. Yep, I fully agree that the Mir team has higher priorities, and I'm certainly not suggesting that those priorities be changed in the near term. Rather, I'm just hoping that Wayland remote desktop support eventually appears on the wish list.

I suspect you're already fully aware of this, but I'll just note here that, according to a GNOME wiki page, remote desktop functionality isn't directly implemented in Mutter. Rather, GNOME Remote Desktop and Pipewire (and other applications that want to implement features related to screen casting and/or desktop sharing) can now rely on two APIs that were recently added to libmutter, namely org.gnome.Mutter.RemoteDesktop and org.gnome.Mutter.ScreenCast. More information here. And this seems to be how Fedora plans to bring Wayland remote desktop support to Fedora 29.

Forgive the naiveté of my question, for I know not complexity of what I ask, but I wonder: Would it be feasible to support the above mentioned APIs in Mir?

@alan_g: In a post on the Ubuntu community forums, you mentioned that you aren't planning to add Wayland remote desktop support to Mir any time soon. Although maybe not soon, do you foresee adding such a feature to Mir at any time in the foreseeable future?