-
@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.
-
FYI: Regarding the snappy confinement, there seems to be some implementation of SElinux as AppArmor alternative for e.g. Fedora or Android (https://forum.snapcraft.io/t/selinux-interface-support/255) so there may be other ways of confining snaps in the future. However if you look @ the snapd support matrix (https://github.com/snapcore/snapd/wiki/Distributions) most distros don't ship with any confinement for snaps at this point (although the wiki seems slightly outdated as not even ubuntu is listed as having the latest snapd version available, LOL)
Still i think (if non-developers are allowed their opinion here ;-)) that maybe snaps might be easier for transitioning from clicks as the hooks/interfaces for snappy are derived from what was used with clicks (pls correct me if i'm wrong)
-
@Mitu,
I'll try to be short this time
UITK
I just built an application using QQC2 Templates, it was just for giving it a look, so it's not a real QQC2 theme extension yet. It's "mostly" based on official specs, including the new style for buttons, except for a few things that can't be done because I'd break compatibility with other QQC2 styles.Packaging
Flatpak is almost agnostic, the current limitation is that has been built just for applications. A few features perhaps are not there yet, but I don't think it's necessary anything more than runtimes, applications and portals. The only potential problem is that aims to be compliant with other FreeDesktop.org standards (i.e. Ubuntu Touch uses a ton of custom stuff in order to limit apps capabilities).
About security, I guess it's everything handled by Flatpak itself, since each app needs to be launched through the Flatpak binary. Apps run in a "fake" file system, apparently.- The flatpak security model – part 1: The basics
- The flatpak security model – part 2: Who needs sandboxing anyway?
- The flatpak security model, part 3 – The long game
About Snaps, it was firstly meant for IoT, then they added support on desktops. Phones and tablets were the last to be supported (paradox since it's an evolution from Click).
Shell
Well, don't get me wrong. I said that the shell is probably the only thing we should develop and design by our own. Mine was meant to be just a provocation: the vision of Canonical about convergence has been proven by facts to be a failure. After five years of development, the whole project has been thrown away. If it ever landed in time for 18.04 LTS, it would have scored 3 years of delay (out of 6 years of development).What we all say we actually want is probably a standard .deb Ubuntu distribution running on a phone. I start to think this article was right. What Canonical was trying to achieve is much different from what we want. Ubuntu GNOME would be a perfect match on tablets.
About Google and Chromebooks: as long as Android apps run on a different OS which provides the same user experience, that's software convergence.
About Microsoft: I've heard they want to develop a single codebase. Anyway, Continuum is a reality since two years now, so seems reasonable they want to do something further.
If a 10" tablet could be used as a PC replacement in specific scenarios, I still think it's pretty hard to think of a phone running as a full desktop replacement: I would likely saturate all the RAM of a Samsung Galaxy S8 just with my normal activities.
EDIT: Ok, this is shorter
-
@demokrit, right!
We probably need anyway to get in touch with Canonical. There are interfaces for Ubuntu Personal/Touch, but I'm not sure they'll be supported in future. Their plan was to deprecate the transitional interfaces for content access, but I guess now they will be the only interfaces used on desktops.For the confinement, the problem is not to run Snap, but running Snap with all the security enhancements. AppArmor itself is not a problem, but adding the module in the Android kernel might be (for what I understand of all that magic @mariogrip & co. usually do behind the scenes).
Click and Snaps are a bit different but, overall, yes, they are meant to solve the same problem.
Any opinion is welcomed here. Don't think I'm an expert here, I just know how to write some code -
mostly by mistake -
@sverzegnassi
Mir
On the mir on wayland topic - I do intend to maintain the android platform on mir, i.e. there is now: https://launchpad.net/mir-android-platform. Canonical has no plans on supporting the libhybris integration. So I plan to add HWC2 in the near future - at least soon enough for Ubports to switch to android 7.Besides that I do think that integrating wayland xdg-shell clients is worth trying - but there are some interesting problems to solve around the trusted prompts and the drag & drop support through content hub.
Snap support and/or Snap based system
- Content Hub and content interfaces are orthogonal concepts - applications communicating via content hub just need access to its dbus interface afaikt
- content interfaces would be used when you want to share libraries between snaps - i.e. qt gtk and other big chunks.
- For an all snaps image I expect that we would still require more interfaces than those that are already inside snapd - for an all snaps image we would have to ship the android user space libraries loaded via hybris either in a separate or inside the gadget snap and then expose access to libhybris out to those snaps that would access it.
Btw there is now android boot loader support: https://github.com/snapcore/snapd/pull/3324
-
@Mitu
Wayland
You do need a software package that acts as a compositor. Wayland is a protocol generator like protobuf + event loop. Mir was created because back then there was no framework to write a compositor. As a result every desktop shell project ended up writing their own solution for everything. None of them have a driver model (see how well the streams integration is coming along). The default EGL integration is bad for system-compositor / session compositor setups... -
Thank you for providing further informations about Mir. I wasn't aware that Canonical dropped the libhybris integration. And thanks for taking care of that!
Snaps
Point by point:-
It's probably easier for me to explain with an example. The LibreOffice snap in the U.Store uses the "Home" interface, which was meant to be transitional. Now that Canonical has no plan for Ubuntu Personal, could we expect similar interfaces to be "standard"? Could they break (in terms of UX and security) the current UT/UP security model, which relies on ContentHub for content sharing?
-
Huh, when I used "content" I was referring to files, document, or more generically data. I wasn't aware of such interface.
-
Yeah, that was my fear. The only example I found for adding new interfaces is this one. My impression is that Snaps have been designed with a strong centralization, afaiu.
-
-
This post is deleted!
