Unity8 for desktop
-
Where we are now
While Unity8 has been most complete and successful on phone and tablet it was always intended that it would also encompass desktop operation.
After Canonical stopped work on Unity8 UBports has focused on supporting and developing phones and a separate project Yunit was working on the desktop case. However, nobody has been working on Yunit for a while now and people are asking on the UBports telegram group about Unity8 on desktop. This is an attempt to give a high level view of the implications.
There are two sets of differences between phone and desktop: the graphics "stack" and the input and display capabilities. Attaching external displays, keyboards and mice to phones allows a switch to "desktop mode" but uses the same libhybris/android graphics stack as for normal phone operation. On "desktop" architectures a different mesa-kms graphics stack is used.
For Unity8 or application developers the differences between these, or other possible, graphics stacks are hidden beneath the Mir libraries, but the distinction is important when installing onto a computer or device.
While all the software needed for the "desktop" installation exists in some form it hasn't been maintained since the Ubuntu 17.04 release. Indeed Canonical has dropped many of the packages from the upcoming 18.04LTS.
The way forward for "desktop"
The UBports developers are demonstrably sympathetic to a desktop variant, but their priority should be progressing the supported deployment onto the phone "stack". If people are interested in desktop they should try to progress it in a way that doesn't distract from these existing efforts.
Late last year I outlined a plan on the Yunit forum. It was probably too late for Yunit but I think much of that discussion is still valid.
There are differences between the UBports and Yunit codebases (and there's likely useful code on Canonical branches) this needs to be resolved.
In short, if there is the will, there is work that could be done.
-
hello guys, I think the work that Canonical did was very big, but also very difficult, I suppose that's why it did not continue with the Ubuntu phone project, the convergence is very difficult to perform but I suppose it is possible, my humble opinion is that it would be better to do the same as Maru OS or Samsung Dex when connecting the phone to a TV screen or monitor, start a second operating system installed that uses the CPU, Ram memory, storage and other sensors to work too, this system could be Ubuntu Gnome, Kubuntu, Xubuntu or Ubuntu Mate, my favorite, I guess it is not the address of Ub Ports, but it could be less difficult and very good option.
Regards...
-
@alan_g As I understood it, part of the initial concept of convergence was that Ubuntu ran on both ARM and X86 architectures... Perhaps as phones get ever more powerful, X86 will be consigned to history, and we'll all just use UBPorts as a true pocket computer. As nice as that scenario is though, I think the vision will have lost something if it doesn't straddle the great chip divide.
-
@3arn0wl I didn't mention the processor architecture as the code can be (and is) built for multiple architectures: i.e. Ubuntu (and, in principle, Unity8) runs on those you mention and several others.
-
Hi @alan_g
Yes I realize that. I was just speculating about future developments. -
@alan_g said in Unity8 for desktop:
Late last year I outlined a plan on the Yunit forum. It was probably too late for Yunit but I think much of that discussion is still valid.
There are differences between the UBports and Yunit codebases (and there's likely useful code on Canonical branches) this needs to be resolved.
In short, if there is the will, there is work that could be done.
Given the demonstrated public interest that continues to surround the Unity 8 project, could Canonical be convinced to contribute one final update that resolves many of these differences (and that, ideally, could be installed on 18.04 LTS via ppa or snaps) before turning the project over to the community for continued development?
-
@gizmochicken even supposing it were motivated Canonical is in no position to do that.
-
I agree that the code is better off in the hands of the community - even if that means that the rate of development is slower. What I am surprised about though, is that the people who were working on the code don't feel a sense of creative ownership and a desire to continue to nurture it.
-
@3arn0wl
There are people from the Unity and Phone team in the community. They, understandably, aren't able to dedicate as much time to the project as they used to be. However, their insight is helpful when navigating the (sometimes strange) depths of the codebase.
-
@unisuperbox
That's good to know.