-
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!
