Hello, I'm new to here.

To be honest I registered only to express my voice somewhere after yesterday's sad news. I've seen the post from Marius that he is going to move on with Ubuntu Phone anyway, so that's why I post here.

I've been eagerly observing the Ubuntu Touch from the very beginning. I've never posted anywhere (apart from reporting one or two bugs), because most discussions were around the Launchpad mailing lists and Google+, which I don't use. I've also bought a Meizu Pro 5 Ubuntu a few months ago and I am generally happy with it (apart from some irritating bugs that Canonical never managed to fix).

From the observations I would like to share my idea on how I see the future for... well, let's call it Unity. Unity OS, Unity Desktop, Unity Phone, whatever. I don't think I can help with development - at least not now. But I hope that my voice expressed here will be able to get to the developers that want to stay and help them find the way for the project.

Let's still fight for convergence!

Yes. This is in my opinion the biggest selling point of Ubuntu Phones. It's something new - something that others don't have yet. Ubuntu and Linux in general has lots of great desktop aplications. The vision of having a PC in our pockets it far too exciting to give it up.

Ubuntu Core can still be a base

I believe that so-called Unity OS shouldn't part with Ubuntu. Canonical is still pursuing the Ubuntu Core and Snaps and after leaving the phone and tablet they will pursue that even faster. It's IoT what they chosen to start earn bigger money on and Canonical's IoT is all about Ubuntu Core and Snaps.

The hardware

This implies two things: there are and will be devices and chips OFFICIALLY supported by snaps. There is Raspberry Pi, there is Dragonboard (so it's a Qualcomm Snapdragon in fact - not too far away from phones!). This is why I believe the new devs should continue on what Canonical started and not finished - moving the Ubuntu Phone and Tablet to Ubuntu Core and Snaps.

Ubuntu Personal

Also I believe that Ubuntu Personal concept (snap based desktop) should still be on the list, so the "One OS to rule them all" still can be created. I believe that snaps have still the potential to make up a secure and reliable desktop with nice permission and dependency management that Snap introduces.

Clicks and debs are not an option

Why? Well, click was kind of beta for snaps. Canonical decied to move away from this because they decided to create something better. And snaps are what Canonical wants to give to the larger community, not only Ubuntu.

Why not debs? To have the proper system images, OTA updates and a possibility to lock the system partition. Without that probably no OEM ever would consider the system reliable enough to put it on production device. And well, commercial app developers will not want to care about the dependencies in debs.

The true Unity leads to Wayland

And here is the - what the history has shown - the Canonical's biggest mistake: Mir. This is what put away the rest of the Linux community and what created the most conflicts and hatered. Moving Unity to Wayland can give you more traction and more developers willing to contribute to the true Unity on phone. And there is one more thing that community had the problem with and now you can ditch: Contributor License Agreement.

Unity 8

The concept of Unity 8 is pretty good for all the phones tablets and desktop. I really like many features of it and the general concept of phone navigation. Also the scopes are a good concept - but they need to start working much faster and better. Let's make them ALL freely installable, so that anyone could install only those he uses. That will generate some benefits:

• The community will not hate us for forcing scopes on users
• The OEM's could install their scopes of their choice by default - customization, ability to sell things with this - more likely to comercially back the Unity OS.
• Well, the scopes developed to work well would be a wonderful way to interact with the content.

And there is one more - Suru design. Ubuntu's font, paperlike themes and iconset. Please do not ditch that as Unity 8 looks really well and the theme, icons and design language is really nice!

Not only Unity 8

As snaps have actually gained some adoption, they can be used to get on Ubuntu Core not only Unity, but KDE and Plasma Active for example - and maybe other DE's as well. A Wayland on top of Ubuntu Core can create a wonderful base for both Unity and Plasma Active. Let's reach the hand to Plasma Active developers, offer them Snaps and Ubuntu Core as base. Maybe they will help in getting Core and Wayland on phones and it would lead us to the common goal - having both Unity and Plasma Active on the phones. And being able to replace one with another with just a snap swap!

Ubuntu SDK

Yet another thing to keep. There is a bunch of cool apps creating with it (Dekko, uNav and more) to be kept. It still may help to reach the convergene goal.

To sum up

So what do we have now? We have Ubuntu Core, we have Snaps and we have Wayland. We have the communities that will develop those and offload the Unity OS's dev team, so that they don't have to develop the entire OS alone. Maybe we have Mir (if Canonical still wants to push it to Ubuntu Core devices), but without Canonical it won't make sense.

So let's take care of Unity 8 and Ubuntu SDK, move it further toward snappification and Ubuntu Core, make a switch to Wayland and pursue the convergence further.

So this is how I see it. Let's create the true Unity - untiy of community with Wayland and the unity of platforms with Convergence. I still keep my fingers crossed for you, guys. And maybe someday I will be able to jump in as well?

@Stefano, chill down. We're all waiting, but let them take time and evaluate it properly. Currently what I've heared that they want an officially supported devices to have official Linage OS available (and, unfortunately, ResurectionRemix is not official, and is probably different in some places from the official). But still, there are many people using Ubuntu on this device, so maybe they will make that exception.

What i suspect is (none of below is confirmed information, it's how I understand things):
It won't be evaluated now, as what they are trying to do is to make Halium and Xenial work for one example device (Nexus 5). Then they will expand it to the core devices that are currently declared to get Xenial (devices they worked with before Ubuntu Touch was dropped by Canonical + M10, as it's the only tablet in lineup) and know them well, have build trees based on Lineage OS ready. For Pro5 they'll have probably to port a device from scratch, as what's left by Canonical is not sufficient to make Xenial work.

I also would really like to now if my Pro 5 gets Xenial or not. But let's give them time, there are many things of higher priority to be sorted out.

However, I would be grateful too if someone from the team clarified corrected the view of the situation I guessed above. Keep up the good work, we are waiting

I am for keeping with Ubuntu Touch unless Canonical forbids to. Why?

1. This OS is still Ubuntu. It is what Canonical created, but taken further without them.
2. Ubuntu Touch will not be associated with the OS that died. If it survives and gains traction, it will be associated OS that was so good that community has been keeping it alive after its initial creators abandoned it.

Ubuntu is recognizable. Don't go for a new name or many people not involved before will just see an abstract, unrecognizable name.

Hi,

I'm writing with a concern I have recently and an idea. Actually I see recently that a few core apps have been updated, however it seems like in terms of design some chaos starts to sneak in.

A little hint of it is between the latest clock app and open store. Both of them have bottom sidebar now, but there are slight differences between them (font size is one thing, the other is that in clock only active tab has a text visible, in OpenStore all of them). It is a little of a problem, but it is shows a problem that needs to be addressed before it gets bigger:

The design consistency

What is happening now is that every developer just does something as he feels it looks the best. The problem is that there is little corelation in what different developers do in different apps. I believe that it is very important for the core apps and system UI to be consistent. Canonical new that and that's why they created lots of guidelines and documentation. I must admit, that they did not manage to keep all apps consistent perfectly (partially because their SDK was a moving target, and they did not manage to put that much resources in the core apps to update them often) - but they had the guidelines and the team, who defined those guidelines and was creating the apps' designs.

The proposal

That is why I would like to suggest a workflow for discussion and approving the designs. It would look like this:

1. The design guidelines should be posted somewhere (or the Ubuntu Touch's documentation should be linked). I am strongly for accurate adoption Canonical's guidelines and mockups as official currently and later on, aftere 16.04 is landed, the guidelines can be discussed - probably in accord with moving the Ubuntu specific UI widgets to QQC.
2. There forum "Design" is created, which is used to showcase, discuss and approve designs (It's the simplest idea, maybe there is an option to use the better tools for the process).
3. Every change in app's UI (adding new feature, changing the design), needs to have it's topic opened by the developer. In the opening post the dev explains the changes and either presents the screenshots of the changes he had done or asks for inspiration/ideas/designs. It is open for discussion then and everyone can make suggestions. It is also checked across guidelines and review by the design team (who needs to accept the changes for the core apps and system UI - let's say by a defined number [ACCEPTED] posts from the design team).
4. During the discussion dev updates and presents the corrected design - it could be also reasonable to include the beta click package, so that people can not only see the changes, but also experience them in action. This is not required though, as many designs will be probably first prototyped, and then implemented (especially for the bigger feature, not just let's change the tab bar or throw in a new switch).

I believe that such design team could also review the current state of apps and suggest their changes/create tickets on GitHub.

The team

Yes, I know that there is no such team right now. I'm not a proffessional designer, though I believe I could help by actively look through designs and making suggestions - maybe also from create a few mockups if I find time for it.

The other thing is gathering that team: I feel like Ubports should more clearly express that they are looking for the designers - maybe a bar on the homepage, subpage informing about the need for design team members etc. (of course if you decide to do so).

Let's open the discussion!

The most important for me are the fixes for Meizu Pro 5 - I have reported a few bugs related to this device and those bugs are making my phone not fully reliable (and it's important for me, as Pro 5 is my daily driver).

Other than that:

• T9 dialer
• Custom SMS sound
• Possibly per-app notification sound (so that Dekko/Telegram notification sound can be different from the SMS one)
• How about listing mediahub apps in sound indicator? It could list the apps, but hide the control buttons where no app is open. When you open the app, it could jump to the top of the list and display the controls.
• System/OpenStore app updates using the transfer indicator, so that they could be downloaded and installed in background and multiple ones simultaneously.

However Ubuntu Phone support on it has a few important flaws, that spoil the experience from me (I'll definitely report bugs right now):

• battery drain when Wi-Fi is on - probably it wouldn't last 24h on standby with Wi-Fil on (I think problems started with one of Canonical's OTA's)
• completely unreliable data connection - it looses the connection and regains it totally randomly, many times when I need mobile data it either drops during browsing the internet or there is no connection at all and I have to restart the phone (even that doesn't always help)
• cellular network is a problem too - it drops from time to time too and sometimes I don't have network when everyone around do have - it says "Unregistered" or "Rejected" (or similar, as I see this texts in Polish)
• I also have issues with call quality - I often have hard time understanding what people talk to me (but this might be just a result of lack of support for "HD Voice" or however it's officially called)

Those are really irritating issues and solving them is vital for device to be reliable, so I would't say that "almost all the bugs are sorted". But who knows, maybe using CM's sources could result in a reliably working system?

Anyway I believe that even if porting requires more work it's worth doing 16.04 for Pro 5, as there is a significant amount of users and app developers that use it, but they won't stay more if they are forced to buy a new device.

I feel that there are a few drawbacks here:

1. It will be problematic for apps having files, which are not easy to classify as a document/music/video/picture (for example sound effects, source files, exportable game saves, compilation outputs, recorded sounds).
2. After recording sound with a sound recorder, it would still add to the music library, which would be very irritating. The same, document viewer would include on its list every source file of an app you develop convergently, as they would probably need to land in the document viewer folder.

In my opinion things should be much closer to what they are now:

1. Each app still has its own directory. Apart from that, there are XDG directories, which can be accessible for apps having proper permission (just as it is now).
2. Make "HubIncoming" directory cleared every time app is closed (or base it on app's flag, so that legacy apps not supporting the new way wouldn't break). This directory's content is never listed in app's file list, music library, gallery etc.
3. After importing, app does whatever it wants with the file. If the file is not needed permanently, it is left as-is and viewed - on closing app it will be removed. If the file is needed, it is moved within the app's cache to another subfolder.
4. Until this step, the changes in Content Hub might not be needed at all, also no new permissions are needed. Here the development of the Hub itself kicks in: multiple actions for application. A Click package can register multiple actions for Content Hub. Having this while exporting you can decide, whether you want to view the image in gallery (for example) or export it. Hypothetically you could export multiple files to the gallery at once. They will be moved by the gallery's code to other subdirectory (Imported for example) and made persistently available in the gallery app. At the same time, you could return to the app from which you exporting without even a need to show the gallery screen at all, and have just a toast from Content Hub saying "Files exported".
5. Public subfolders are only good in some cases, but the current approach to them is OK. For example camera is a source of pictures that should be generally available - that's why it places them in public Pictures folder, where it has its subdirectory to indicate the source. The same approach could be used for music streaming app (such as Jamendo client for example) - you could quickly download a song and place it in app's subdirectory in music. When you do this it is also instantly available for the stock Music app.
6. The other case which needs to be changed in Content Hub is announcing the source path to the destination app, so that it could be used to prevent importing if source file is accessible as-is.
7. Content Hub also needs an option to have a default apps for mimetypes. Exporting a file should allow to specify, whether to use the default app (best for viewing files) or show a list. File manager could have "Open" and "Open with..." actions to trigger.

I also believe that text file editor build in file manager is not a good idea. People might want in future use different text editors. That's why clicking on a text file should trigger Content Hub and not the internal view/edit mode. Also I believe that the full-fledged app for file editing should be present, so that it could import files via Content App from the other apps as well. Having the option to set the default app to view the file will solve the problem of having to choose an app every time.

For sideloading, your approach makes it slightly easier, but stiil I think it is not a problem to put a file via MTP in Downloads folder and import it (and move to permanent app storage) to the app (your game boy example).

I'm also not a fan of app subdirectories in public folders, as it clutters them. It's a nice approach for apps that are source of publicly available media (such as camera app), however I wouldn't like to have a separate directory in ~/Documents for almost every app I install. Let's leave the Documents directory for the documents themselves.

On the other hand, I believe that there should be an option to create a custom directory in the home folder (for example Projects or Dropbox), which could be available for MTP and apps that user explicitely permits. In that case the Game Boy emulator could create a directory ~/Game Boy Roms, where you could sideload ROMs via FTP. They could be accessible for multiple emulators as well. This approach could be great for custom content types, such as mentioned ROMs or developer's projects accessible for example from Seabass.

Yay, that's wonderful news! Tkank you!

@UniSuperBox
Thanks for answering! Too bad I don't use Telegram and probably will not register now (maybe if I needed to because of more discussions on Ubuntu Phone I would). But I'm open for conversation here. I can join IRC from time to time, but too bad that I cannot read the chat history

Someone has already forked the Unity 8 here: https://unity8.org/ But I'm not sure if it is the right approach to have every single project in its own independent team. It may lead to chaos. In my opinion Ubports devs should take on organising the project and as quick as possible take these actions:

1. Make a big, public anouncement that the team is forming to continue the project. Publish it everywhere possible so that everyone could see that there is the team, that the team is big and strong and is willing to help everyone jump in.
2. Choose a name and set up the web pages, chats, mailing lists and overall platform, where the community can discuss. A kind of hub which would consolidate all the project from Unity 8 through snap phone images to Ubuntu SDK and applications.
3. Contact as many Canonical developers and designers directly. Request them to share all the information, plans, designs and everything else what could speed up resuming development. Find out who of them would like to help. Have a chat with Ubuntu Core team to find out their attitude and how Ubuntu Core can power the phones.
4. Create development infrastructure if possible.
5. Make a long statement on where we are, what we want to achieve and what is the plan.

And what I would suggest for the start of the development:

1. Focus only on existing Ubuntu devices end maybe those for which a port already exists is stable. I know that the more phones the better, but main focus should now shift to the core.
2. Set up a small team to find and fix the most irritating errors (crashes, network, battery) and release one or two bugfix OTA-s, so that Click based system is more stable and reliable.
3. Simultaneously start efforts towards creating Ubuntu Core images for both desktop and phone. Take (in the beginning) the 64-bit officially supported by Ubuntu devices: bq M10 tablet, Meizu Pro 5 phone and 64-bit desktop. Try to snap kernel, drivers and whatever else is needed to create the first running images.
4. Move the Unity8 from Mir to Wayland. Allow the KDE Plasma Active team to jump here to help and create their snap as an alternative to Unity desktop.
5. We are there - focus on stabilizing those, Unity 8 development for convergence, maybe start integrating Ubuntu phones with Ubuntu desktop (even if they are on seperate devices), fasten the app development, create a proper app store.
6. After the first official, stable snap image is relased, push further on porting to new devices and finding way to cooperate with hardware manufacturers.

After showing off first snap sucesses the croudfunding campaign or even setting up a foundation might be a good option.

And do not get angry with Canonical too easy, but cooperate closely with them, contribute to snap. Their business decision was to give up the convergence, but its development would be definitely be a profit for them (more snaps, etc.).

That's my view, I am waiting to here your voice as well.

These are just fan mockups and not the official ones. I would suggest to split this topic in two - one for official plans/mockups from Canonical and one for community ones.

The problem with the second category is that as they can be beautiful and neat, they are often completely clashing with the current design. For example music taskbar app looks handy, but I personally cannot see the way to mix it into the indicator design - especially that it is not only meant for one music app, but generic.

I think @sverzegnassi has been working on the Suru style for QQC for some time. Would you share some information on what the status is and if anything has been done not only to style, but also SDK components (bottom edge, headers, swipeable list items etc.)?

I decided not to take up any work in it currently and focus on an idea that might someday evolve into a decent app. I'll not shere more information though, as there is still a long way ahead and the entire thing is uncertain.

But if the app will approach to materialization, I'll definitely consider implementing in QQC2 (if Suru style and component set is in good shape enough by this time), and maybe help out with the SDK in that time.

I've skimmed through now.

My view is that actually convergence is the only thing that may become the selling point someday. Of course there is a number of obstacles which I also listed in my post.

Why? Well, without convergence how does Ubuntu differ from Android or iOS?

• It's free, open source, privacy focused. But Sailfish is too, Firefox OS was as well. None of them succeeded as well. Given the Android and iOS have so many users, unfortunately few people care about those.
• It more tweakable and less locked. Well, hardly a good selling point as well, unless its target are developers only.
• It has different UI, navigation patterns. Again, it depends on individual preferences. Existing Android and iOS users may be very hard to move away from OSes they are used to.

The entirely new thing you can do with your phone

I believe that mobile market is a very hard one and the only way to jump in and get a significant share is to find a niche where noone is present yet - and to show people that with Ubuntu Touch they can do things which they cannot do neither with Android, nor with iOS etc. I don't mean things that they cannot do this way or that good, that fast, etc. I mean a quality change - things that they cannot do at all. I see convergence and an option to ditch laptop for some people such a thing.

Relased before it was ready

Also please note the other reasons that are mentioned in the post you linked: convergence was marketed as it was actually done and ready, but in fact it was far from it. Unity 8's functionality is far from finished for desktops, UITK as well, many desktop apps looked bad or didn't run properly when M10 tablet went on sale. I think that was a huge mistake to try selling convergent devices without having delivered the minimum viable product in terms of convergence.

Hardware

And again, the hardware. As Miracast has failed as an alternative to HDMI and few phones provide the MHL, the convergence usability is limited with what we currently have. No to mention the problem of convergent mode with charger cable plugged in. This is why I said that we are not there yet and the correct way is to sell the convergence is to make it work flawlessly first, then create the device that allow users to use the full potential of convergence and then market it and show off the value that convergent phoneputer adds to their lives.

Ubuntu Edge

On the other hand - Ubuntu Edge didn't get funded, but it has actually broken croudfunding record gathering more then 12 million dollars. I believe that the goal was set extremely high (and probably needed to be in order to make it happen), but still the traction it gained hints that there might be a future for converget devices or phoneputers.

Hello,

I'll throw in the little idea I've thought of recently.

More then the phone

I mean buzzwords. It all started with a phone - but once the phones became more advanced, a few buzzwords appeared to indicate that the emerging devices became more then just a phone. I mean words like smartphone and phablet.

They are definitely more friendly then palmtop or PDA, and currently from being just a portmanteau they entered our everyday languages.

Even more then the smartphone: convervence

What Canonical had tried, and Ubports is still trying to do, is to start another revolution. From typical phones, we have currently moved to the point where we perform some of the tasks, which had required us to use a computer before, on our phone. We have phones that are smart, but are not yet our computers (of course in some ways they are, but we still use the laptops to perform most of tasks while we are not on the go).

Ubports is trying to push this further. Once convergence is funcionally finished, seamless and fully ready for everyday use also for non-power users, it will allow a number of groups of people to actually not have the computer at all - in a number of everyday tasks a convergent phone will be able to fully replace the computer.

And that is the game changer, which, in my opinion, deserves a new buzzword: a phoneputer.

What the heck is a phoneputer?

I believe that a phoneputer is - as the name suggest - a device that is a phone and computer at once. A device that can be used as any of them (or better - both at the same time) In my opinion to call a device a phoneputer it needs to:

• allow to connect a monitor, keyboad, mouse
• allow to plug in a pendrives or other types of USB devices that can be plugged to the computers
• allow to work in a PC mode on the external power source
• enable to install and use apps as easy and freely as on the computer
• allow users to organize their files, content, open and save files with different apps

Does the OS for phoneputers already exist?

No. However I think that combined efforts of UBports and Canonical is furthest on the way to it currently. Android is not currently an OS for phoneputers, as it is completely not optimized for desktop usage - and, what is more important - it does not allow to run any kind of desktop apps. Windows seem to have come pretty close, but the problem is definitely lack of desktop apps compiled for ARM, which could be installed on the phone and run in a Continuum mode.

Ubuntu Touch is different here: it allows to run desktop apps in convergence mode. It is not yet as polished as it should be for a phoneputer, but the main bits are already there and it the rest is under development.

Why I stated "combined efforts of UBports and Canonical"? Not only bacause of Canonical's effort that started it all, but mainly because of the snaps. Growing number of desktop applications is being packed as snaps. Although those apps are not convergent and they do not adapt to phone form factor, they probably will be able (and definitely should be able) to be installed on Xenial even if they are only usable with a monitor plugged in.

So in my opinion to make Ubuntu Touch an OS for phoneputers we need to:

• have the easily installable snaps (probably via OpenStore)
• enabled by default, polished convergence.
• allow application to request more free access to the home folder (possible via snap slots) - in that case we could have for example the confined package with an IDE, which we could run on a phone and freely modify the projects residing in the home folder
• allow user management
• provide a way to use a background services (while handing the easy control of them to user) - a phoneputer should definitely be able to run for example a constant, background Dropbox syncing (I think that the app could ask user if it can run background processes and there should be an indicator listing all apps, that currently run anything in the background and allowing to kill or suspend them)
• provide power settings to allow easily switch on/off suspending background apps (power indicator?)

Still a way to go. But at the same time huge chunk of work is already done!

Does the hardware for phoneputers exist?

Unfortunalely, no. And I don't meah the power - current multicore beats present in flagships are definitely sufficients. What is lacking? Honestly, a few really simple and doable things:

• more then one USB port. It is a must for a phoneputer, as it needs to be able to have a monitor, keyboard and mouse plugged in and charge at the same time. An alternative is the wireless charging, but this is a limitation in my opinion. So two USB ports are a must - one to plug in the charger and the other one to plug in a dock or a hub. At least until someone creates a way to charge the phone and use the devices using the same USB port, but I don't think it is possible.
• Given the amount of software compiled for ARM this architecture is sufficient, but still I hate the fact that Intel quit their Atom for smartphones developments a few years ago. An x86 Atom would be a perfect CPU for a phoneputer - not to mention the porting related simplifications the fact that much more code could be shared between mobile and desktop flavors of the OS.

A perfect plan?

Well, kind of "simple", but probably very long term: nail the convergence to make it seamless, simple and powerful, allow installing snaps and take time so that OS could mature enough. Then move to a second step: find a business partner and crowdfund a first phoneputer ever - a device like nothing before: having 2 or 3 USB ports (supporting USB displays, USB Audio, fast USB 3.1 v2 etc.), allowing to connect via USB at the same time a charger, a monitor, a keyboard and a mouse. And then market and sell it as a full-fledged phoneputer to make some people never need their laptops again.

• Wi-fi: not improved - battery still won't hold a day with both wi-fi and mobile data on.

Update for my TD-LTE Pro 5 after a few days of testing:

• Reliability: partially improved - 4G signals seems to be present more often and connection drops in the city are less frequent. However it still isn't prefect - I have just saw the "Rejected" note in the message indicator and had to turn on and off the airplane mode - sometimes I still have to do it as well to regain the Internet connection.
• Battery life: improved - phone did manage to live for 2 days with the data connection on. It was impossible before. I think that still some significant drops exist, but they don't have to be related to the modem.

I'll try testing the wi-fi now to check whether the battery drain is acceptable.

What is still to be tested is the radio signal at the remote areas but I haven't moved away from the city recently. So far I think this radio should definitely be included in the future Ubports updates.

WOW, you're GENIUS!!!

It changed. Let's see if it does correct anything for me unluckily having the TD-LTE device...

Thanks!

It still won't solve the navigation pattern conflitcts though. I still think that even pure QML apps as scopes are an overkill for both performance and UX reasons.

The current concept of what scopes are is not bad - they just need to be faster, more flexible and dynamic.

@vadrian89 said in Scopes current and future:

any QML app can be set as scope and be at the user's fingertips
webapps can be loaded as scopes through WebView / WebEngine to support HTML / Javascript scopes

This is definitely not a good idea in my opinion. Apps' navigation patterns would interfere with desktop navigation, what would mean that having set unav as a scope you would not be able to swipe between desktops.

Scopes definitely need their API standards, and some limits in the functionality, so that they could be fast, safe and not breaking the Ubuntu's UX.

Of course what scopes are and how they work is definitely what shoud be rethought and redone, but still "whatever" is not the right answer.

@TartanSpartan
OK, I somehow missed your 4 points. None of them will work.
1-3. because of no recovery could modify the LXD image and swap a file that's inside it.
4. because baseband is in a different place for Android and Ubuntu. Even if it wasn't swapped back during flashing back tu Ubuntu (and almost sure it would be), the baseband used by Ubuntu is in a different place and another instance of it would be used.

The only option is probably to rebuild the device image with the new baseband. However that would require a person with proper knowledge to invest his time, and I guess all of those person (probably devs) have more important work to do with pursuing Xenial...

I'm more and more keeping my fingers crossed for Halium for unified OnePlus 5/5T to appear, and move to 5T...

@TartanSpartan - no, it's not the case. That was one of the hypotheses that I had, but the problem turned out to be different: the baseband is inside the LXC container, so it is in a different place than in am Android phone. Because of that you cannot flash the baseband using the method meant for Android phones.

In fact you cannot just flash the baseband alone anyhow - you probably need to prepare the system image with the new baseband.

What renders us unable to replace the baseband at all unless we want build something similar to what a custom ROM is for Android I think...