Group Details Private


  • RE: Issue priorities - basic phones features shouldn't be the first ?

    Little the same as i wrote on github,

    Also please understand, we are a small team with a huge task, we have many moving parts and moving to a newer version of mir and unity8 at the same time is not helping, we are doing our best to make an an awesome operative system. but we are in a really busy period after taking over from canonical, we updated to xenial, we are updating mir and updating unity8 all these are huge since canonical left it all the current version far behind the latest releases, this forces us to make major changes. We are also building Halium and following the evolving of android and newer devices to be able to follow the mobile marked. At halium we are also trying to move our sensor, gps, media and camera system over to an active maintained system instead of maintaining our own. And we are also looking at merging our patched in celluar and pulse with an active maintained one. Once we move things to active maintained systems where we can work together to get to the same goal, we will then get more time to focuses on core functions.

    About replacing the browser, this is an huge part for us, we are not able to maintain our own fork of chromium (oxide) that why we are forced to move the browser, this move will in fact give more time to focused on the core functions on the phone.

    We are moving to newer version of pretty much every part of the system, this is a major work. Once we have done the major upgrade we will get a lot more time. And in fact we are really close go get to this point, we now are super close to finish all the mir/unity8/libhybris upgrades. And we don't have a big enough team to focus on all the bugs right now as the code may have merge errors to be able to merge with never version and to risk spending lots of time on bugs that might be fixed in newer version. that's why we are upgrading, getting our source aligned with newer sources to then focus on fixing and improving.

    In fact most of these bugs comes from the canonical days, they was a much bigger team then we are right now, so we don't work at the same speed.

    We are doing our best with the small team we have.

    OTA 8 will include new mir and unity8 (and many other updated parts), we hope these have many of these issues fixed, but we have to expect some bugs to be included also since the upgrade is so major.

    Thanks for understanding 😉

    posted in General
  • RE: for device-tarball question

    @kuailexs Sorry that it took a little, i had to setup eveything, but Its mostly ready now 🙂

    Do you have an gitlab account? If so whats your username? That way i can add you to the repo.

    I have setup an repo on gitlab where you can push your files, those will then get automatically pushed to our infrastructure and pushed to the system image server.

    The format inside this is same as device tarball with, partition images in partitions folder and rootfs files in system folder.

    Required files are:
    partitions / boot.img
    partitions / recovery.img

    Files should not be compressed, our infrastructure will do this 🙂

    posted in Porting
  • RE: Morph Browser is exellently trackable

    This is defiantly something we should resolve within the browser (at least have an option to block ads and trackers) But the browser is quite new and still is under heavy development, i do expect something like this to be added in newer versions.

    Right now using blocks most ads and trackers.

    posted in General
  • RE: for device-tarball question


    This is awesome! 🙂

    We have something called community channels where there is no requirements other then it needs to boot. These channels work exactly like the other channels, only difference is its a community supported device.

    For the normal channels, it will need to have all the supported hardware/important parts working. But we can move to the normal channels once its 100% supported.

    If you would like an community channel, i will gladly setup one and give you the details how to upload new images etc 🙂

    I just needs some info to be able to set it up,
    Is this based on 5.1 or 7.1?
    does it uses 64 or 32bit user space?
    What username do you want on the channel?
    Do you use edge or the normal devel?

    posted in Porting
  • A personal road blocker


    As you may or may not have seen, i have been a bit offline last week. This was due to one of my close family member got into hospital with an serious infection, it was so bad that he got picked up by the ambulance. And since I'm living in the same house and is really close to this person, this has not been an easy week for me. This is the reason why i have been gone, but with all this said, hes now back home and in much better shape, he is still recovering but overall doing fine. and I'm slowly getting back to everything.

    Thanks everyone!

    posted in General
  • RE: semantic versioning for UT

    @alan_g Yes that what i meant, sorry a mistake.

    posted in OS
  • semantic versioning for UT

    With the new idea for changing up OTA process, I also want to propose new version system that makes sense.

    I propose to use Semantic Versioning


    This way we could completely get rid of framework and only rely on the version to describe both version and api/abi compat. It would also give you a lot more info about the version you are on example that a major bump has a much bigger change then for example patch.

    MAJOR: bigger change that Breaks ABI/API
    MINOR: adds backwards-compatible bug fixes, changes and functionality (may break smaller library ABI in really special cases, but this should be notified about!)
    PATCH: adds backwards-compatible bug fixes.

    Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

    This would be how our different channels would look
    1.6.2-beta2 -> 1.6.2-rc1 -> 1.6.2
    beta -> rc -> stable

    This way you would know what version becomes what, example you know that 1.6.2-rc will become 1.6.2 stable.

    This fits great in with the "gotta go fast" proposal by dalton, here is an example how that would work

    1 week:

    • 1.5.6-devel0
    • 1.5.6-devel1
    • ----- / ----- Devel continues like this daily
    • Last weeks rc becomes stable: 1.5.5-rc1 -> 1.5.5
    • Last devel build of the week becomes rc: 1.5.6-devel6 -> 1.5.6-rc1

    2 week:

    • New devel version starts: 1.5.7-devel1
    • Last weeks rc becomes stable: 1.5.6-rc1 -> 1.5.6
    • Last devel build of the week becomes rc: 1.5.7-devel6 -> 1.5.7-rc1
    • This continues weekly.

    Then monthly we do a minor bump with more advances feathers.

    We could also do a mix between slow and fast, where we are releasing stable monthly:
    1 week:

    • 1.5.6-devel0
    • 1.5.6-devel1
    • ----- / ----- Devel continues like this daily
    • Last devel build of the week becomes rc: 1.5.6-devel6 -> 1.5.6-rc1

    2 week:

    • Devel continues daily
    • Last devel build of the week becomes rc: 1.5.6-devel12 -> 1.5.6-rc2
    • This continues weekly

    Then after the month is over last weeks rc becomes stable: 1.5.6-rc1 -> 1.5.6


    xenial stable: 1.6.2
    xenial rc: 1.6.2-rc0
    xenial rc: 1.6.2-rc1
    xenial devel: 1.6.2-devel1
    bionic devel: 2.6.2-devel1

    We would also make a clear build date in settings, this way we can know we are on the latest build.

    posted in OS
  • RE: Unity 8 Open Store In desktop design

    This look really nice 😄 but it look little too much like google play. But i would love to see a similar design but using more suru design instead of material.

    posted in Design
  • RE: Apps using Oxide

    @doniks Yes there will be a transition phase, we wont "just remove" oxide 🙂 The phase time really depends if and how many apps it breaks, since we keep Ubuntu.Web we really hope the transition would be minimal.

    What i meant with 100% QtWebEngine is that every part that is "pre-installed" like browser, web container etc would be moved over, not that we would remove oxide.

    Ubuntu.Web will still exist and will not go anywhere, It will still be based on oxide until oxide is removed, once oxide is removed it will be moved over to QtWebEngine so it will continue to work (unless it uses oxide only apis)

    The oxide api will be removed at some point, when is still unsure. We would need to go over and see how many apps use this raw, and how many apps will break as an result of this. We will also try our best to create a compat layer to be able to make the transition without breaking apps (like webapps+)

    posted in App Development
  • RE: Apps using Oxide

    We are moving 100% to qtwebengine/morph on devel really soon this week.

    For native webapps they would magic move to qtwebengine since we are changing the container code. webapps+ is a different story since they import oxide, they have to be ported.

    Ubuntu.Web is ported to qtwebengine, but depreciated.
    Morph.Web is the new library that's based on Ubuntu.Web so its backwards comparability with it.

    For qml apps using Ubuntu.Web without using oxide specific apis would "just work" without needing to port them.

    Oxide will be removed, so this is where you would need to do "porting". Most apis are similar or has similar options. Any app that import oxide has to be ported.

    Morph.Web is mostly qtwebengine but with user agent scaling for convergence + some other fixes to make it work better for phones and desktops, this is a small library. I really recommend using this.

    import QtQuick 2.4
    import Morph.Web 0.1
    WebView {
         url: ""

    I will make a more of a "guide" once devel is out with 100% QtWebEngine.

    posted in App Development