Hi all,
I've written a few notes about my plans to add CardDav support to Ubports in the ubports-dev mailing list:

https://list.ubports.com/pipermail/ubports-dev/2018-March/000005.html

Ciao,
Alberto

Hello everybody

I'm glad to announce that on November 2nd I'll be giving a presentation of Ubports at the 4th Linux Piter conference, which will be held in Saint Petersburg, Russia. The sessions will be recorded, and I'll update this thread with a link to the video, once it gets published (approximately one week after the event).

The audience, as far as I've understand, will for the most part be composed by IT experts which work on different fields than mobile phones, but I still hope that some of them will become curious about our project.

Time will tell

Hi all!
Today I uploaded a new version of account-polld in the ubports overlay PPA, which as far as I understand will be used to create the image for the "devel" channel.
account-polld is a background process which is always running in your device, and which gets waken up every 5 minutes to check if you have new notifications from your online services. At the moment, it supports gmail, twitter, google-calendar, caldav and dekko (gmail accounts only). This new version doesn't change anything of that, but takes a few steps towards the plan to allow click packages to install their own account-polld plugins.

In this version, account-polld has been completely rewritten: it has moved from being a monolithic binary written in go to a slimmer Qt/C++ service which runs the plugins as separate processes, on demand. For simplicity, the existing plugins have been reused and are still written in go, but they could be written in any language (they could even be shell scripts!).

Even though this version doesn't offer noticeable changes for the end user, you might be happy to know that the memory footprint of account-polld has decreased, as reported by top. Before:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3391 phablet   20   0  919520  12764   8896 S   0,0  1,3   0:00.89 account-polld

and after:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2979 phablet   20   0   60368   6328   5448 S   0,0  0,6   0:00.20 account-polld

It's just a few megabytes (look at the RES column, and keep in mind these are kilobytes), but on embedded devices every byte counts.

Testing!

The new account-polld has been tested and approved while I was still working in Canonical, but things were moving slowly and we never managed to land it. So, it may be that it hides some dragons
I myself use only the gmail plugin, and I've verified that it's working. Notifications for dekko don't appear to be working, but OTOH I haven't seen them with the old account-polld either. If you are on the devel channel or have a writable filesystem (install account-polld and account-polld-plugins-go from the PPA) please give these new packages a try and report any regressions.

Last but not least, the code for these projects is here:

• https://github.com/mardy/account-polld
• https://github.com/mardy/account-polld-plugins-go

Note: the instructions in this post are for expert users only, or for those who don't mind having to reflash their device if something goes wrong.

---

Hi there!
I've lately been working on a native application to watch videos from Youtube and other online services, without ads.

While the application works on the desktop, in Ubuntu Touch it's totally non functional because the media-hub component supports local media files only.

After some hacking on the media-hub and qtubuntu-media I got the videos to play, even though the application is still far from stable.

You can see a video here: https://youtu.be/wTygEsa_Er4

Now I want to have my patches to media-hub reviewed, but first I need to be relatively sure that they don't introduce regressions. The same component is responsible for playing videos and audio files, so both the Media player and the Music app need to be thoroughly tested.

If you'd like to help, please install this PPA in your device, which can be done by running the following command from a terminal in the device:

sudo ubports-qa install xenial_-_remotemedia

This should force the update of the media-hub and qtubuntu-media packages; if that's not happening, another option is to just download the deb files for armhf from here and here and install them manually with dpkg. After doing that, issue the command

initctl restart media-hub

or (better) restart your device, and verify (with the media player and music applications, mainly) that there are no regressions.

You can then install the MiTubo click package and try to play some videos from Youtube (following the steps I did in the video linked before), keeping in mind that this could crash and not working reliably. But what I'm mostly interested in knowing is that existing device functionality is not being broken.

Ciao,
Alberto

Hi there, I just released a VNC client application which I built using clickable + QBS, probably the only build system which I like.

I wrote a blog post to announce it, but while writing the post, I realized that there was some information that a developer could find useful, so I'm copying that here:

Development of a UBports Qt/QML app with QBS

If, like me, you are a fan of QBS, you might want to have a look at the source code of CuteVNC (yes, the project was born as "Lomiri VNC", but since it's a generic QtQuick.Controls 2 application, there was no need to tie it to the Lomiri environment); there you can find a QBS module for UBports applications, which can help in filling in the manifest file and deploying other Ubuntu Touch specific files into their proper install location.

You can also see the configuration file to make clickable build a QBS-based project. In my mental task backlog I still have the idea of making clickable support QBS out of the box, but the integration of the two technologies is so easy even now, that I gave this task a quite low priority.

A class for computing viewport transformations

Last but not least, a developer might find useful the generic Scaler class I wrote to compute the viewport transformations: it's a simple, QtGui-only C++ class which takes an input structure with the viewport information, and returns a similar structure containing a QTransform matrix to map item coordinates to coordinates in the source object coordinates (in my case, the source object is the remote screen served by VNC) and some other useful parameters, such as the scale, center offset, and the painted area rectangle.

The class has a 100% line and branch coverage in the unit tests, so I hope I can rely on it.

At the moment, the project has identified itself as ubports: this site, the github repos, the patreon page, it's always "ubports".
I think that if we want to move constructively, we should take one step at a time and instead of immediately proposing new names, decide whether we want to keep "ubports" or change. If we decide to change, then we'll have a chance to think of a different name.

As for myself, I'm all for changing. "ubports" is just a nightmare to pronounce, and to most people (even geeks) it means nothing -- the link to Ubuntu is far from being evident. Besides, the "ports" suffix reminds of porting, but the project now has grown into something considerably bigger than that: it's a full O.S. which we'll be maintaining ourselves.

Hi all!
I've found the github group for ubports and I see that there are a few repositories in there. However, it's not clear to me where the various bits of code are. For instance:

1. How is the image generated? Where can I find the list of debian/click packages preinstalled in the image?
2. Where are the actual packages taken from? Are they taken from some PPA as it was the case for Canonical images, or how?
3. In the community Q&A, it was mentioned that A-GPS support was added; where can I see the change in the code which enabled that?

I hope that these questions will help me and other people who want to contribute

Hi all,
I've written a length e-mail to the development mailing list here.

Your input is very appreciated, either in the ML or as a reply to this forum message.

Ciao,
Alberto

Hi all,
I started working on porting UT to this device (I have the 6/128GB version). Almost nothing is working at the moment, but I got Unity8 working, at last.

I've written a blog post with all the gory details in my blog.

BTW, if you own this device and would like to run UT on it, your best bet is to join this Telegram channel (this is not based on my work).

Ciao,
Alberto

This topic is a hot one, widely discussed in Canonical too:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1358294
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1499971

UX designers have always consistently said that all application data should be removed when an application is uninstalled, for the simple reason that the user wouldn't know how to find it or recover it. Some developers have pushed back against this decision, because, well, developers know how to recover this data.

I do agree with the designers: data should be deleted, but the user should be informed about that and should have a chance to abort the uninstall process if he prefers to save his data first.

Hi all,
I started working on porting UT to this device (I have the 6/128GB version). Almost nothing is working at the moment, but I got Unity8 working, at last.

I've written a blog post with all the gory details in my blog.

BTW, if you own this device and would like to run UT on it, your best bet is to join this Telegram channel (this is not based on my work).

Ciao,
Alberto

@alan_g said in Introducing Miroil:

What follows may not be the best way to hack Qt, so suggestions are welcome. Starting from the previous post:

sudo ln -s /usr/local/lib/qt5/plugins/platforms/libqpa-mirserver.so /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/

Allows Qt to find the platform.

You can also try:

export QT_PLUGIN_PATH=/usr/local/lib/qt5/plugins

instead of symlinking the Qt plugins. I believe there's no need appending the other system plugins directory as it should be somehow already embedded in the Qt libs.

Though, if you are using a (virtual) marchine specifically setup for this goal, it might be better to just set the install prefix to the system Qt:

cmake \
    -DCMAKE_INSTALL_PREFIX=/usr/ \
    -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu \
    ..

The arm64 version is now in the store. I have no idea if it works, though

Please let me know, if it doesn't work.

@kugiigi Thanks. If I didn't make any mistakes in publishing it, it's here: https://open-store.io/app/it.mardy.lomiri-vnc

Is the Xperia an arm64? If so, indeed, I didn't build it for arm64. But let me give it a try...

Hi there, I just released a VNC client application which I built using clickable + QBS, probably the only build system which I like.

I wrote a blog post to announce it, but while writing the post, I realized that there was some information that a developer could find useful, so I'm copying that here:

Development of a UBports Qt/QML app with QBS

If, like me, you are a fan of QBS, you might want to have a look at the source code of CuteVNC (yes, the project was born as "Lomiri VNC", but since it's a generic QtQuick.Controls 2 application, there was no need to tie it to the Lomiri environment); there you can find a QBS module for UBports applications, which can help in filling in the manifest file and deploying other Ubuntu Touch specific files into their proper install location.

You can also see the configuration file to make clickable build a QBS-based project. In my mental task backlog I still have the idea of making clickable support QBS out of the box, but the integration of the two technologies is so easy even now, that I gave this task a quite low priority.

A class for computing viewport transformations

Last but not least, a developer might find useful the generic Scaler class I wrote to compute the viewport transformations: it's a simple, QtGui-only C++ class which takes an input structure with the viewport information, and returns a similar structure containing a QTransform matrix to map item coordinates to coordinates in the source object coordinates (in my case, the source object is the remote screen served by VNC) and some other useful parameters, such as the scale, center offset, and the painted area rectangle.

The class has a 100% line and branch coverage in the unit tests, so I hope I can rely on it.

2.) issue is when during playing some media network is not fast enough and buffering of content is necessary, playback is not paused and it will skip part of the media

I think I noticed this too. I've now reported it as a bug. Thanks!

Note: the instructions in this post are for expert users only, or for those who don't mind having to reflash their device if something goes wrong.

---

Hi there!
I've lately been working on a native application to watch videos from Youtube and other online services, without ads.

While the application works on the desktop, in Ubuntu Touch it's totally non functional because the media-hub component supports local media files only.

After some hacking on the media-hub and qtubuntu-media I got the videos to play, even though the application is still far from stable.

You can see a video here: https://youtu.be/wTygEsa_Er4

Now I want to have my patches to media-hub reviewed, but first I need to be relatively sure that they don't introduce regressions. The same component is responsible for playing videos and audio files, so both the Media player and the Music app need to be thoroughly tested.

If you'd like to help, please install this PPA in your device, which can be done by running the following command from a terminal in the device:

sudo ubports-qa install xenial_-_remotemedia

This should force the update of the media-hub and qtubuntu-media packages; if that's not happening, another option is to just download the deb files for armhf from here and here and install them manually with dpkg. After doing that, issue the command

initctl restart media-hub

or (better) restart your device, and verify (with the media player and music applications, mainly) that there are no regressions.

You can then install the MiTubo click package and try to play some videos from Youtube (following the steps I did in the video linked before), keeping in mind that this could crash and not working reliably. But what I'm mostly interested in knowing is that existing device functionality is not being broken.

Ciao,
Alberto

Hi @manland!
I'm the one mostly taking care of the Online Accounts feature, but it's a bit bizarre, because I myself make very little use of the online services we support (Google, Twitter and Facebook), so unless someone notifies me of some bugs, I would hardly notice if they stop working.

I would appreciate if you could file a bug (or two, if you find issues with both Facebook and Twitter) in https://github.com/ubports/account-plugins/issues, describing the problem in detail. I don't have a device with me right now, but I'll try reproducing the issue ASAP.

In general, yes, you should use the Online Accounts feature, because it simplifies life both for you and for the end user, who won't have to login multiple times, when different applications use the same account.

As for the buteo-sync-plugins-social, the long term plan is to use it, at least to fetch the contacts so that you can have them in your address-book; but it will never be a replacement for a full-featured client, so I very much support your idea of creating a native client.

Ciao,
Alberto

@dobey said in Language packs as click packages: call to arms!:

@mardy Are we discussing language packs as clicks, or a more general solution to "what apps are installed by default" when flashing a phone? Because those seem like two separate things, and we should not use one of them as a reason to do another thing (or to not do some other different thing instead), I think.

I'm not using one as a reason to do the other, but rather I'm explaining how I imagine this evolving into, to convince you that we can get a nice user experience even with selectable language packs.

I also disagree with the idea of anecdotal argumentation of well, it's a waste in the rootfs for me, so why should it be there for others. I think it would be best to not go down this route. There are plenty of things in the rootfs which are meaningless for me too.

And what I'm suggesting is that, if those things could easily be installed as clicks, and if doing so would save a considerable amount of space, then it's something we might want to try out. It's a question on whether it's worth the effort.
I did start with language packs because I thought that it would be an easy pick, since they are data-only. And so far it looks like it's something easily doable.

[...]

Maybe having langpacks is something we will need to do in the future. But I think right now, we should not rush into this as a solution to the problems we have, as there are plenty of larger concerns at the moment. And if we rush into it, we will be stuck for a long time, even if we discover some other solutions to whatever problem this is meant to solve, instead.

I'm not requesting that people spend their time on this. If @bhdouglass told me that he has no time to review the changes I'll eventually submit to the Open Store, then I certainly wouldn't force him, but it looks like he likes the idea as well.
And I'll try not to rush: I do want to see a good implementation of this (especially because, as I said, I plan to apply a similar scheme for navigation data, later on).

Could I spend my time in a better way? Probably, but I'm doing this as a hobby in my spare time, so I tend to work on those things that interest me first

@dobey said in Language packs as click packages: call to arms!:

We just got rid of gdbserver/libc-dev, which freed up a huge amount of space. The only reason we have size problems with the image now, is because it's never really been optimized, and we just keep adding new things to it.

Sure, and soon we'll get rid of Oxide, I guess, so the future is at least a bit rosy. But having this lot of data which I don't need in the rootfs is a waste, you'll agree.

My aversion to langpacks stems from the fact that they are an anti-feature, and a premature optimization. How they are done is implementation details. One doesn't have to install any extra packages on Android to get foreign language keyboards. Core apps may be fully translated, but vast majority of 3rd party apps will be missing translations. To me, langpacks are just another way to sweep some problems under the carpet, so we end up ignoring them, rather than fixing the real problems.

It's not a premature optimization, it's a way to get rid of 307 MB (and more, in the future). The way that this feature is exposed in the user interface matters a lot: it can range from the ideal situation (the user doesn't notice, and all the langauges he needs are already on the device) from the worst one (the user needs to open a terminal and type some obscure commands to install the language packs, after which the device enters a reboot loop).

The way I see it, we are close to ideal situation, for the very simple reason that (unless everybody agrees otherwise) downloadable images having all the language data preinstalled are not going away. As long as the device can accomodate them and users don't complain about lack of space, that's undoubtly the best solution.

Now, what I want to do is part of a greater and much more evil plan: customizable images (and also, possibly, changing the way that clicks are preinstalled on the device). The idea would be that the flasher tool would offer you an option:

1. Download and install default image
2. Download minimal image + select individual click packages

Case #1 is like nowadays: all languages will be preinstalled. In case #2, the flasher tool would let the user select among click packages to be added on top of the base image: language packs, sure, but also ordinary applications and other click packages types that will appear in the future (I've a plan to add click packages with regional map data and wifi information for location lookup). I haven't yet thought how these will be installed on the device, but thinking out loud, I see these possibilities:

1. The flasher tool downloads and install the clicks itself
2. The flasher tool simply writes the list of clicks into a configuration file on the device, which will download and install them during the first boot
3. Something in between (downloading the clicks from the PC, copying them over, but installing them on first boot)

The nice thing about this, no matter how we implement it, is that the flasher tool could remember the list of clicks the user has selected, and use it as a default selection for the next time. Or it could also try to read the list of the click packages installed on the connected device and prompt to use that, instead. And I bet there are more possibilities for making users' lives easier that I haven't thought of.

Anyway, the main idea is to let the user select the extra packages, and remember this list across installations and backups. And I believe that if this is done in the right way, users will on the contrary appreciate the feature (and they could see the device boot up in their own language on the first use, imagine that! )