i guess i‘m still not that relevant here - i’m not yet an UBports or Ubuntu Touch user yet, neither Android or Tizen, but i’m quite curious about the potential UBports can have everywhere (smartphones, tablets, smart-tvs, game consoles, etc.)
@Flohack Well, I'm not worried by Qt itself: it's generally well-documented (property and method deprecations too), so anything can easily (in general) be set up to prevent issues.
The problem comes when we take in account UT-specific code, which makes usage of Qt private imports. I see, running 'grep' on my local folder where I keep all the UT code, that more than 10 components depend on them - including Unity8, the web browser, the Ubuntu UI Toolkit, the Ubuntu keyboard, and some Mir helper.
It means this software should be heavily tested in order to check if there's any regression. This is what Canonical used to do anytime they were moving to a newer version - IIRC they had to fix a few things when they moved to Xenial which uses Qt5.6.
A (partially) good news is that everything should have been already tested on Qt 5.6 and it should just work "out-of-the-box". Anyway I don't think there's any value in moving from the current patched version of Qt 5.4.x to another - as long as we stay on vivid, Qt 5.4 is not the problem.
I think this should be one of the main discussions after we've started to work on Xenial. Qt version, UITK, Unity8, Mir, and the package format are things extremely related each other. The only thing that I can say for sure is that it wouldn't be a problem if we were on Snaps, Flatpaks or Appimages, since they bundle a specific version of the required libraries... :/
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!
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.
@Flohack I know that any DBus call - except for some - is by default denied by AppArmor, therefore we should for sure update the confinement AA templates.
I think we'd probably need to define a new AppArmor profile for headless apps, in order to prevent e.g. usage of the UriHandler service
@Flohack I think my plan may have to be convert all my friends and anyone I know to Telegram, that may be easier lol. I was talking to a developer friend of my last night and he was saying that although everyone uses Whatsapp, he prefers Telegram as it has multi device support. That got me thinking that this may be a way to get more to Telegram and build up the base user numbers.
@doniks There is no way I know of. You are either stuck with not really functional flo's image or you flash the deb stuff on it again but you'll have to say good bye to the bluetooth and camera.
Yeah, seems like. I have switched back now by replacing the android lxc system.img inside the ubuntu system image in the new flo installation with the one from the ubports device.tar.xz . Camera and bluetooth gone, sound and video back, but ota13 remained.
Also, judging from the kernel configs, it seems that in the flo image there is a newer kernel, but I cant see any difference in the running system.
The only way to fix this is either to somehow compile the whole image on your own
I wouldnt mind doing it, Im just stuck. I was staring at repo manifests, Makefiles and lunch, brunch scripts, but I couldnt figure out what I would have to do to get the source tree I got with repo from either ubports or canonical to change it such that it builds a flo image. Also, I would suspect, that 'just' building it would only bring you to the point without bluetooth.
or ask the owner of this server for some help - if he would be kind enough to talk to you.
Didnt get very far there. Dont wanna put words in his mouth, but seems he doesnt have an N7, so he cant really test.
In any case, good luck - I was stuck at that point long enough to lose interest :(, that is the only reason why I got rid of my N7.
@WLBI You will be able to use larger displays later on, if you want. BTW: David Hunt made a PiPhone 3 years ago ( https://www.youtube.com/watch?v=8eaiNsFhtI8 ) ... With some optimization, which the ZeroPhone does, this really is a complete handheld computer and phone. Maybe even almost entirely open source soon, because open GPU-drivers are coming along, and there are efforts for an open firmware.
@apple.muncy Thanks for the reply and for the bug tracker link :)
In that case, since development is active, any updates on the missing components like camera and GPS, being added to the "working" list? :) I don't want an ETA (I know better, I've modded enough phones in my time with ROMS from XDA, to know not to ask for ETA's ), I'm just excited at the progress this project has made and I want to install it on my OPO :) Currently though, no camera and GPS (which I rely on daily), are a deal breaker to me :(
[quote='mariogrip' pid='54' dateline='1434298331']
I tried to set console=null on my oneplus one and it gave me and kernel panic, so i really think you need to console=tty0 and remove androidboot.console.
Hey @mariogrip !
Long time has past and I investigated a lot.
My device [b]can't boot without a console[/b] (for many reasons that I can't even totally explain).
So I need to find a way to fix the crash and make Ubuntu Touch accept console flags.
If you know some Canonical Devs, could you ask them why the console is disabled ? And even what's make the kernel crash ?
What I can see from today is a few possible workaround: You could explain that calls in the beginning will need an announcement by a normal message, which will be delivered by then hopefully still working notifications, and then the other party can respond by switching on Telegram an start a call ("You have a callback pending...") - As there are no costs involved, its just a not-so-comfortable way. Active calls would be possible.
I do not like the idea of a centralized messaging app. Many other unified messenger have failed to deliver what people want: Simply all features. Telegram is so special already that a unified messenger again has to make compromises regarding which features will work, which wont. My goal is to have 100% feature parity with the official client.
The current plan is to catch up with the most important features first (supergroups, secret chats, 2-factor auth etc) and then stabilize the code as much as possible.
You can see on Github the Issue list and where we are targeting the issues to. Currently we are targeting for 3.x release for the next months and 3.1 probably end of year.
@Aury88 The problem here is not whether or not doing such transition, but how.
Unity8 is a complex software (~110k lines of code) which has a huge number of dependencies, from the Ubuntu UI Toolkit to GLib, from LightDM to LibIndicator and AccountServices, and all the other components specifically written for U8: Scopes library, Ubuntu Download Manager, Ubuntu Keyboard, MediaScanner2, MediaHub, Thumbnailer, and so on...
Mir is just one piece of the puzzle. Before touching any single line of code, it's important to know every single dependency of Unity 8, and be sure that all the building infrastructure works properly (i.e. being able to successfully run all the test suites of these components).
What really concerns me is not moving from Mir to Wayland, but getting a proper estimation of the development costs.
I'm not sure that going forward with the Canonical idea of convergence ("One OS running on every device") is the best way to get things done.
I have the impression that having a single shell on different devices (phones, tablets and desktops) adds a lot of complexity to a single software, and Canonical probably got stuck on that.
I haven't seen yet any other project trying to do the same: Microsoft decided to develop two different OS's: only "Universal apps" and the UI Toolkit are shared between the two platforms; KDE is doing the same, developing Plasma Mobile and a convergent UI Toolkit called Kirigami; and ChromeOS is not Android, but it's able to run its applications.
Also, there's another fact I haven't seen any mention yet: moving Ubuntu Touch to Xenial would actually break any compatibility with the apps and scopes currently available on the Ubuntu/Open Store. Canonical had an hard time (since 2015) to figure out how to do such transition, and they never moved from Vivid (i.e. Ubuntu 15.04) as base for their Ubuntu Touch images.
Every new version brings a lot of new features and correct a lot of bugs. Try the rc-proposed channel is relatively stable.
Can't wait to have the 9th version.
Thank you again for the great job you're doing!
Looks like your connection to UBports was lost, please wait while we try to reconnect.