Best posts made by Mitu

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

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!

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.

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.

As I stated in the other thread - in my opinion the drawbacks are not worth it.

1. We will never manage to have the compatibility enough to run the apps people need (Snapchat, Messenger, Services) well enough - we would need a whole lot of Android's bits.
2. For those that could work flawless it will be probably easy enough to create a native counterpart.
3. Sailfish had the company doing it, free software, wayland, its own phone and Android app compatibility. It failed. And I've never come up for an article saying "look what awesome app is being developed for Sailfish!"
4. The reason is simple: If I can run Android app and use it (even if it looks out of place and not everything works), then why should I care for native ones?

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.

@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.

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.

Hello,

I have a few thoughts on Content Hub's direction - let's open the discussion

1. Read-only mode:
   Let's say I have a music file, being for example a recording. I'd like to play it in a music app or media player app, but without exporting it and adding to library. Could it be possible in future to have to have a view option, so that I could just play it via music app, but not copy to its directory? Alternatively, it could be copied to a kind of app's temp directory, which would be cleared every time application is closed and not listed in file lists, media libraries etc.
   I think it could be a default behavior for many apps, such as gallery or music app - they could by default just view the file, but have an "Import" action, which would move the file from the temp directory to app's Imported directory, as it's done automatically today. The other option could be modifying the file in temp directory in app and export it to another app as "save". In that way I could open a text file via text editor (in temp dir), edit it and export it to file manager to save it (or to Dekko to email it) - without storing it in text editor's dir, or even without the need for text editor's dir as well. Some apps would not need the storage directory - they could allow only to view files and export them to other apps.

2. Multiple actions per app:
   For example gallery app could be used for either viewing the photo, or editing it. Content Hub screen could be rearrange from grid to list view, and apps could list its actions if there was more then one.

3. Exporting only when needed:
   I'm browsing my photos folder using file manager and want to - let's say - .zip a few of them. I want to check, if the file is the photo I want in my archive. I open the file with gallery and the file is exported and duplicated in gallery (the other copy of the photo appears at today's date) despite the fact that this particular file is actually in folder accessible from Gallery app all the time.
   I think that Content Hub should detect such case and prevent exporting it again. Insteadm, app just should be made open its own file.

Doable?

Does this mean that Ubuntu Core images could be relatively easily delivered to devices that support Halium? Could it potentially allow Ubuntu Touch to be moved onto Ubuntu Core as Canonical planned before they ditched it?

In my opinion Ubuntu Core based system and snaps as a primary app distribution format for 16.04 or later at some point could be now discussed again, as it is definitely an argument worth evaluating.

What's more, Ubuntu Core is going be treated with new series bianually (http://ubuntudesign.github.io/docs-demo/snappy-dev/ubuntu_core_desktop/), thus by the time Ubports is moved to 16.04 (as I guess there are still pretty much a few months to go) there will be Ubuntu Core series 18 at least in tests. Wouldn't moving onto Core unload quite a big chunk of work and code maintainance from Ubports then?

By the way, to be not misleaded by the thread title: it's not that you will be able to install snap applications on your Android phone at some point - it's rather that Ubuntu Core will be able to be booted in a similar way to Android, thus potentially simplyfying delivery of Ubuntu Core image for a device that runs Android out of the box.

Yay, that's wonderful news! Tkank you!

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.

Artificially breaking compatibility is definitely a bad idea. IMO the best option would be to allow Anbox work as a third-party app - if you want it, you can download it from the store and use it - but not as a core functionality of the OS.

Would it be possible to be distributed as as a click or snap in the open store?

But one is inevitable - once option to install Android Apps appears, there will be much less (not none at all, but less) reasons to develop native apps. Telegram client for Ubuntu Touch for sure would have never been developed if users could just run the Android version.

I also think that Android apps compatibility should not be the priority. Did it attract people to Sailfish for example? I don't think so.

And again: if I can have an Android app on Ubuntu phone, then I won't need the native app. And that's why the Ubuntu app ecosystem will not grow that fast with Android compatibility.

Actually that would be the last nail in the coffin for Ubuntu. Never, ever develop compatibility if you are the underdog.

Exactly.

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.

Clicks will not be easy to be left. Canonical began to do that, but hasn't finished. It is a long way to move phones to Ubuntu Core, but is should be in my opinion continued.

In the meantime click-based Ubuntu Phone should be updated once or twice. But only to fix bugs - the most energe should be put to the snap transition.

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.

@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...