-
As for software center, I think that we may use Canonical's snap store. Many snaps for all form factors are landing there. But it would be nice to create an app that could support multiple snap stores. Whether we need our own store is not so obvious dor me.
But yes, ubuntu push is to be moved somewhere else.
-
I agree with that. I know snaps would make things easier, but unluckly it's too soon to leave click apps. Users still depend on them.
Let's see where (and when) Canonical is going to left us at our own way...
-
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.
-
Most of you have probably seen it, but here's the link to yesterdays UBports community Q&A:
-
@Mitu said in A vision of where to go after Ubuntu Touch's death:
And what I would suggest for the start of the development
You've made a very nice summary of ideas here, but for the start of development it may be important to distinguish much more clearly between what's genuinely needed versus what might be helpful at some point in the future.
Probably the most valuable thing that can be done as a starting step is just to look at what are the minimum set of changes needed to complete Unity 8 on its own terms (and "complete" in this sense probably means finalizing a viable desktop). No major re-architecting or trying to replace important bits of the stack -- just try to follow through on the final touches of the project as it exists, the kind of stuff that Canonical's team would have been doing if the project had carried through.
The reason to do that is because, by trying first to understand and complete the project on its own terms (i.e. the convergent OS where the same codebase can serve mobile, tablet and desktop), everyone involved will learn a good deal about the actual issues of the project, and about why its developers made the choices they did.
From that vantage point, everyone will be much better placed to make informed decisions about what really needs to change in the long run -- whether it's what to do with Mir (it may not need to be replaced at all given Canonical's ongoing plans for it in IoT projects), whether a new app store is necessary (it may be possible to continue to use the existing snap store just fine), or any of the other considerations that might come up.
-
@UniSuperBox can u share how i can join chat on telegram for ubuntu touch
-
@Hsabun You might have to use the browser or webapp to join, the UT telegram client does not support supergroups (a telegram feature for groups with more than 200 people) and invite links yet. That's why we are currently maintaining two groups, the UBports Fan Club (supergroup) and the old UBports group, so that people on Ubuntu Touch can still chat. We're looking into fixing supergroups on Ubuntu Touch at the moment, but I can't make any promises...
-
Keeping it alive. Ubuntu touch could help a lot of open source graphic illustrators like the development of paint apps that uses stylus.
-
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.
Seems to be a very good advice. the abrupt end of the project may drive some individuals toward a personal commitment and support for the project .
has anyone tried something in this direction? -
@MrHoliday This is not very easy, because Canonical laid off more than 100 employees, that's most of the phone and Unity 8 team, so the responsible people are not very easy to reach and getting an official answer from canonical proves to be very challenging. However, we are in touch with some (former) Canonical developers and designers and some even joined our team (unpaid and in their free time of course, what we are really grateful for).
-
@NeoTheThird I agree on that one, it would have been much nicer of them to involve us since they knew about our project quite well. They could have get us some last minute contacts to organize the takeover. But we are more or less alone, and our network to former employees is not that huge.
-
@Flohack said in A vision of where to go after Ubuntu Touch's death:
They could have get us some last minute contacts to organize the takeover. But we are more or less alone, and our network to former employees is not that huge.
Bear in mind that it might not be legal for them to pass on (former or current) employees' contact details to you without those people's explicit permission. And since those people are probably quite busy sending out CVs and suchlike at the moment, they may not be very responsive in the short term even if they want to get involved with Yunit/UBPorts.
-
@WebDrake I know, this is a big part of the problem... Let´s see how we can continue with what we have.
-
@Flohack I would give it time. I don't know about other people, but personally I'm not placing any expectations on UBPorts or Yunit for quick results -- I'd much rather everyone just took some time to patiently explore the codebases that exist, than have anyone feel pressured to get things done straight away.
-
@WebDrake That's a very reasonable approach and it's also what we think. Still, for some problems we need answers asap, because we don't want to allow for a gap between the end of canonicals support and our takeover... We'll see how it goes.
-
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?
- The toolkit. Working code and many apps based on it.
- The beginning of the new (2.0) toolkit planned to be transited to Qt Quick Controls.
- Suru design language. A beautiful and well thought-out approach to applications UI. Designed for convergence.
- 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.
- 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:
- 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.
- 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).
- The mockups should be moved somewhere in case Ubuntu Design webpage disappears someday.
- 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:
- Snaps are actively developed by Canonical, further development of Clicks would be yet another task for Ubports' devs.
- 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).
- 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.
- 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.
-
@Mitu , I'll try to reply point by point.
UBUNTU UI TOOLKIT
Where we are?
Nothing to add here.
The legacy
Well, I also have the specifications for each component of the UI Toolkit. I never mentioned it in the Telegram group since I'm not sure if it's a good idea to publish an internal document. In any case, for the design we're almost fully covered.
UITK devs, anyway, weren't planning to use QtQuick Controls 2.
Ride With Us: The Road To UI Toolkit 2.0Let's use it then!
I'll be pragmatic. UITK devs wanted to keep their "custom" code for the 2.0 release. We simply can not.
We need to consider a few things first:- We don't have any traction from Canonical trying to "force" its own standard, both in community and commercial products.
- We need to be appealing with third party developers so that they support our platform. The more we use standard (upstream) technologies, more developers would be interested in supporting and using our stuff.
- We don't have resources to support an UI Toolkit written from scratch (~200k lines of code - if it's worth to mention it). How many of us are interested in maintaining a toolkit that was about to be refactored in many ways? If we have no people working on this, it could be a problem.
Just going a bit technical, a bit part of the Ubuntu UI Toolkit is not necessary anymore:
- Screen Pixel Ratio is not required anymore. QtQuick natively supports high-DPI screen since Qt5.6
- Theming and Styling. QtQuick Controls 2 already implements support for theming, it works nicely, and it's easy to use.
By the way, in order to add a bit of context at the original discussion (which started on Telegram), I was porting the Suru design language (used by Ubuntu UITK) on QQC2. This was the result of just a few days of work.
The required effort to support QQC2 is extremely low, and it would help us in case we want to distribute our apps on other platforms.
CLICK AND SNAPS
I'd like to use Ubuntu Core too. So, a big +1 from me. An interesting consequence about adopting Ubuntu Core (if it's a viable solution, of course) is that whatever the shell will be, it could be ported on RaspberryPi 2/3 too, with just minor changes. That would simplify development a lot, and would help UBports in recruiting new forces.
Anyway, I would enlarge the discussion, including Flatpak too.
Snaps
- They are developed by Canonical. They still have plugs for Mir/U8/UT, but Canonical is still pushing its technology on desktop now. How can snaps be useful for us in our goal to converge? Most of the apps in the store support only those "transitional" interfaces. Our content sharing model, based on ContentHub, would be broken, I guess.
- Snaps have interfaces. Not sure how the current set of interfaces would fit with our confinement model. Extending the set of interfaces doesn't seem something easy to do, since they are hardcoded in "snapd". (not sure though - needs exploration)
- ContentHub has been written in order to integrate with Click and Snap confinement policies. And no, that copying files around was actually a feature, not a bug.
Many core app developers, included me, asked Canonical to whitelist core apps, but it hasn't been allowed. (If we want to keep ContentHub, BTW, what we surely need is mime type support)
Clicks
I see some advantages in keeping clicks. However they won't fit in a long terms, since they heavily rely on what the single platform offers. To be brief, we can't force developers to adapt to a platform with a low adoption. It should be the other way round. But as @Flohack pointed out, they could be preferable on low-end devices, because of their low memory requirement.
Flatpak
- It's a FreeDesktop.org standard, so we can expect support on any major distribution. This is relevant for political issues.
- I was having a look at the KDE
interfaceportal implementation for their apps. It seems it could do the work ContentHub currently does on UT. Plus, it seems to be easily extendable, and to provide an easy way to track hardware usage or content access for each app (I saw some GNOME design proposal). - Anyway we still need to provide a .deb-based image, unless we move to OSTree (however, at that point, what's left of Ubuntu?)
- No AppArmor requirements in the kernel. That should make it easier to support legacy devices.
Summing up
- Click is preferable since we could avoid to deprecate support on legacy devices.
- Flatpak seems to be more flexible and would give us an extra traction on different distros.
- Snap is almost equivalent to Flatpak (except for AppArmor req.), but, as an extra, we could provide the whole system image as Snap. However, it seems we can't use Snap on legacy devices.
Just a note on memory management. It's Unity8 that uses ~400-500MB of RAM, so I think it's better to fix the issue there. Also, if we ship a more recent version of Qt libraries, we could benefit of all the performance and resource-usage improvements Qt did since version 5.5.
I'd be more than happy to give up on the ability to run 4-5 apps in background, if I can use the latest version of the OS.Furthermore, Oxide vs. QtWebEngine
I'll be extremely brief. When the Oxide development has started, there was no QtWebEngine (Chromium-based) alternative. What to choose? QtWebEngine. Like for UITK, I don't think maintaing a Chromium fork is in our current abilities.
Furthermore #2, the Shell
I'm probably looking for a flame war here. But even Unity8 needs to be discussed.
This is probably the piece of software we won't replace, since it would be the core of any convergence strategy we'll decide to adopt. And it's where we might need to lead any design decision.My considerations here are personal concerns:
- We all want convergence. But what does really mean "convergence"? We have more ways to achieve convergence, even Canonical tried different approaches (e.g. Ubuntu for Android - abandoned because no OEM was interested in).
- Just for records - don't take it serious - for the M10, we could even consider to run Ubuntu GNOME directly (its UI would be easily adaptable).
- A single codebase is not really necessary, see what Microsoft of Google did with UWP and Chromebooks.
- If we plan to support ARM devices, we wouldn't need any "Mir on Wayland" solution in a short-term then. Just Mir is enough, and Canonical is still keeping maintaing it.
- What about Yunit? I'm not discussing their possibilities to success, and I'm happy to see that a former Mir/U8 developer has joined their forces. I'm just talking about the common efforts. It's still unclear to me which kind of collaboration has been publicly announced. It has been said "we'll collaborate", but since now I haven't seen anyone (Marius G. excluded, which is extending support for Wayland in Mir) really willing to take changes.
- Why don't start anew, writing a new software on QtWayland at that point? Or, on phones, we could still use e.g. Lipstick.
- How much time would take to develop something new or to add support for Wayland in Unity 8?
It has been told (I can't find the article now) that Unity 8 would have required ~4-6 months of further work, in order to work properly on desktops. Now, with Mir not being developed for desktops anymore, without those resources Canonical employed on Unity 8, it could require ~12-18 months, or even more. Are we sure people will still be interested in Unity? Or that other projects (e.g. KDE) wouldn't improve their mobile projects (e.g. Plasma Mobile)?
I'd start any discussion on these topics by considering which are our current internal and external limitations. It potentially implies some compromise, but what I personally want to see now is my apps running and being distributed both on phones and desktops of any kind (no matter whether it's Ubuntu, Fedora, OpenSUSE running Unity, GNOME or KDE).
-
Thats a huge answer...
-
@Flohack LOL! Just the bits about Unity, I guess... Discussion about packaging is mostly about what we've discussed on Telegram
-
@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.
