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.

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?

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.

Yeah, and get sued by Orange carrier

I would go with something abstract or a single word used in everyday. And make it not contain "Open" or "OS". It's very generic in my opinion.

Unless we can stay with Ubuntu Touch, as this is recognizable an I am for sticking to this name as long as possible.

About Canonical letting the OS down - well, I think it is more important that they created Ubuntu Touch. Without them Ubports would not exist. And - so far - the OS is still Ubuntu, just became unofficial flavour. It is still planned to be upgraded to Ubuntu 16.04 and not diverge away.

An update: Let's converge!

A few things have happend since I started this thread. I have some recent thoughts that I would like to add to discussion - especially regarding convergence:

Ubuntu UI toolkit

Where we are?

The current situation is not too happy I believe: there is an SDK abandoned by Canonical using ony the custom controls (created before QtQuick Controlls have landed). Those custom components have no adoption outside of Ubuntu Touch ecosystem and they are probably not portable.

Another problem is that other Qt apps, GTK+ apps etc. do not integrate graphically with Ubuntu Touch, which is a pitfall as well if we wanted to deliver the seamless convergence. A sweet spot would be if you couldn't tell the toolkit without at a first glance when looking at a siple app (I don't mean the situation where toolkit specific widgets are used etc. of course).

The legacy

So, what we are left with?

1. The toolkit. Working code and many apps based on it.
2. The beginning of the new (2.0) toolkit planned to be transited to Qt Quick Controls.
3. Suru design language. A beautiful and well thought-out approach to applications UI. Designed for convergence.
4. Ubuntu design page - there are the gui guidelines and tons of mockups - including those not implemented yet but showing the direction Canonical had with the toolkit.
5. Canonical design blog - there are some app mockups that can be invaluable for continuing both SDK and Core Apps.

Honestly? It's a lot!

Let's use it then!

I wasn't aware of the UITK2.0's existance until a couple of minutes ago. So there goes the plan suggestion:

1. In general I believe the UITK vision and concepts are unique and cool and apps like core music app, Dekko and uNav proved it. I am totally for keeping it.
2. Canonical realized that Qt Quick Controls are the base to move onto and that is the best plan I think. The UITK2 repo has appeared on GitHub - it should be evaluated and forked. Most probably in cooperation with YUnit and under their GitHub team (if they will want to do this).
3. The mockups should be moved somewhere in case Ubuntu Design webpage disappears someday.
4. The goal should be to have the two things: one is a portable Ubuntu (or Suru) style for QQC (who knows, maybe it could even pushed upstream to Qt?) which could be used to style anything - including existing QQC applications written without UITK in mind and a portable library providing a set of additional components - AdaptivePageLayout, Ubuntu's list items, bottom edge, headers etc. There should be no duplication though - Ubuntu buttons, label, checkboxes, radio buttons etc. should be dropped in favor of Suru styled QQC.

Clicks and snaps

On this topic I'm still in favor on snaps and even moving to Ubuntu Core (to be precise I mean wrapping Halium-based images into core, os and gadget snaps to make the Ubuntu Core images out of them). I know, there are many different thoughts on this topic, it's just my opinion (as the whole of this post, frankly). Let's list the reasons I see now:

1. Snaps are actively developed by Canonical, further development of Clicks would be yet another task for Ubports' devs.
2. Snaps have interfaces. It can be worth to investigate them, as they can allow to build the awesome permission system - where the apps could hypothetically declare their own permissions (such as Dekko declaring permission to read mails that are stored somewhere inside its snap settings - you could decide in system settings what apps can read from dekko).
3. Maybe it could be possible to replace content hub with a set of snap interfaces. Maybe it could be possible to avoid copying files around and multiplicating them every time you pass it from app to app. In my opinion apps should be able to read (for example for viewing) files from other apps without copying them to their own directories.
4. Convergence. If we want convergence, there will be the need for incorporation probably both snapd and flatpak in the images (and not to use things such as Libertine to install desktop apps at some point of time).

I think that's all for now. I'll keep posting any further ideas for discussion here.

I'd mark myself as potentially interested in that port too, especially considering the unified 5/5T build.

I'm currently on Pro 5, but possibly OnePlus 5T might be my next phone.

Are there any hopes for fixing connectivity (telephony signal, mobile data) related bugs on Pro 5? My phone is VERY unreilable in this matter and I believe bugs like that should be the first ones to be fixed, as they affect the core functionality of a phone.

I've created proper tasks on GitHub, however they are not tagged for OTA-3.

@sverzegnassi
Wow, that's a truly huge answer!
So again, point by point:

Toolkit

Oh, I have had understood things wrongly. I was sure that UITK 2.0 was going to be based on QQC.

I am aware that the toolkit was to be revamped and totally agree that there is no point to develop it in a current shape - closely tied to Ubuntu and isolated from upstream and other distros.

Therefore my vision is not to follow the isolation path, but - as I mentioned - transform the UITK into a style and set of extensions for Qt Quick Controls that would be distribution agnostic. To put it simply, UITK would become a library to create convergent apps using Qt Quick Controls (and some new controls based on them). The goal would be to rewrite all the Ubuntu specific controls (swipable list items, adaptive page layout, bottom edge etc.) to be based on the Qt Quick Controls and replace all duplicating ones (labels, buttons, etc.) with those from QQC. Apart from that create a QQC style being an incarnation the current Suru design.

When we are there, try to implement the styling and components that are present on mockups that did not manage to come true - new buttons, context menu etc.

I believe toolkit made in this way could gain some traction both inside and outside the Ubuntu community.

With "Let's use this" I meant mostly the concepts, mockups and design since the code of UITK 2.0 isn't there. And as you pointed that moving to QQC was not a goal, let's change this one point of Canonical's vision.

According to your experiments: wow, interesting. Have you used some QQC's header or tried to reimplement Ubuntu's one and base it on QQC? To be honest it could make it as a starting point for the... hmm... let's call it Suru QQC Extensions

Packaging applications

I believe that one of the most benefits of snaps are confinement, interfaces and of course snap images. How does FlatPak cover this? Does no AppArmor mean no confinement? It may be simpler to implement, gain traction and be used with legacy devices, but how does it address the security?

Snaps (as Clicks before) have been created with phones/tablets/other devices in mind. Flatpak is probably more desktop oriented. Will it address the issues Snap already does or require another solutions to be implemented anyway? I don't know Flatpak that well to answer those questions.

QtWebEngine

Well, Oxide is now abandoned. Moving to QtWebEngine would probably have excactly the same effect, but without need to develop the engine. I fully agree we should move.

Shell

Well, honestly if we dropped Snaps, Unity 8, UITK... what makes it Ubuntu Touch. If we did this, let's just join forces with KDE on Plasma Mobile and Kirigami, introduce convergence to KDE, wait for Halium, create OS based on that and port it.

I believe that a single codebase has important advantages - ability to run the same app on phone and the desktop and seamless transition to desktop when you dock your phone. I think that this is the heart of convergence - having your PC in your pocket. Microsoft's and Google's approach? Chromebooks are not the convergence - you can just run Android app on the laptop, but not the other way around. And there is no docking - a phone doesn't become a desktop. Microsoft tries (or tried) to do this and they are thinking about the single codebase as well. But with all their power in my opinion they have failed.

I believe that it's Ubuntu who started to do the convergence right. It is an enormous amount of work, I fully agree. But I don't think there is a way around. We can do the less work, but then we will not make the convergence a reality.

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 1.5x would be enough, but yes - it should be increased a bit.

Disclaimer: I have not yet decided to start this at all, as alone I will have neither enough time nor skills to develop it. However, if a few more people joined, it might be possible to happen. Even in that case not in the nearest future.

Hello,

I'm thinking about rebooting the UITK. However, my time and Qt skills are not sufficient to develop and maintain the project alone. I'm sharing my vision though to ask if there are any people which would be interested in joining - in that case maybe it would be possible to start indeed.

Vision - meet Suru UI

I think that calling what I would like to achieve a toolkit is a bit overkill, the reasons will be explained in this post. Also it would be no more tied to Ubuntu. I believe Suru name is good though - it's a design language that I would like to continue.

Qt Qucik Controls

That the toolkit should be rewritten - but not from scratch. Qt Quick Controls should be took as a base. On this two new modules should be build - modules that are independent from Ubuntu and can be used seperately as well as both together.

Suru Style

The first part of the jigsaw would be the QQC Suru style. I would like to strictly follow the designs created by Canonical and recreate a look and feel they intended to create with UITK - including color pallette, Ubuntu font-based shapes, etc.

However, I would not like to mimic what we currently have on Ubuntu phones - insted I wish to look ahead and follow the design guidelines which hadn't materialized before Ubuntu phones have been axed.

The reference is here: Ubuntu App design guidelines contains much detailed information and lots of mockups packed with it. Mockups depict a popup menus, radio buttons, new styling for buttons and more. This is the style I would like to strictly follow.

Suru Controls

The other part would be Suru Controls. Its goal is to provide an extra set of controls that cover the UITK's convergent functionalities - bottom edge, swipable list items, adaptive page layout, headers with actions etc. The controls should be style-agnostic and - if possible - ready to be used with whichever Qt style (however using them with other styles is less important than functionality).

Suru Controls should be based on QQC 1.x - QQC 2 are not available in Qt 5.4, which is currently used on phones. If the version was bumped someday, Suru Controls should be moved too.

What for?

Well, for whatever. Someday Suru UI could be adopted by core apps (if they find maintainers), Yunit... but also many other third party developers who currently stay away from UITK because it is not portable.

What would be the plan?

1. Estabilish the development: gather developers, mockups, guidelines, create repository, GitWhatever project etc.
2. Create Suru Style at first and make it cover the controls available in standard QQC.
3. Create the additional controls. Move one or two smaller core apps to Suru UI to be able test on them.
4. After the functionality is in place, we can think what more can we to achieve even better convergence experience - new designs, controls etc. But still with respect to the current UITK concepts - rather to enrich them not to replace them.

As I said before. It's a thing I would like to do, but my time and Qt experience are very, very limited - and even if the team managed to be created, I probably wouldn't be the most active developer in it. I am posting this though to share the vision and look around if there are any people here willing to join forces.