I've written a few notes about my plans to add CardDav support to Ubports in the ubports-dev mailing list:
I've written a few notes about my plans to add CardDav support to Ubports in the ubports-dev mailing list:
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
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
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
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.
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-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:
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.
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.
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
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.
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.
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:
I hope that these questions will help me and other people who want to contribute
This topic is a hot one, widely discussed in Canonical too:
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.
The vivid image was never on that server. Indeed, the current
crossbuilder does not support Vivid; you could try using an older version, for example this one, but to be honest I'm not very optimistic about the chances of success: I haven't been working with Vivid since a long time.
[...] I am currently using syncevolution on the command line for this which is not a very user-friendly but functional solution. I would be very grateful if you could make sure that any replacement of the current backend will only happens if the new approach provides the same set of features regarding synchronization.
Hi Kalle, I'll certainly take that into account. Can you please tell me exactly what commands you run in order to do the synchronization?
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:
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:
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! )
A) There's a development list?
Yes, but it feels like I'm the only one using it
Please nooooooo. We don't need to have langpacks at all. it's an outdated anti-feature in Ubuntu, created to fit the live ISO on smaller CD-ROMs. We really do not need them. We really should just include support for all languages we support, by default, and optimize irrelevant things out of the image if there are space concerns.
But we do have this size problem. Saving 300 megabytes is a huge thing. And someday we might want to include text to speech or speech recognition programs, or other language-related features (AFAICT, word prediction is now enabled only for a few languages), so it's easy to predict that this size will grow even more. What exactly is the problem with click language packs?
I suspect that your adversion to the language packs stems from the way they are used in Ubuntu; if so, I fully agree. I do not understand why we need to have locale data in
/usr/share/locale-langpack/ in addition to
/usr/share/locale/; and even worse, in some cases we do have the translation files in both directories for the same language/program, where the translations files are different, and I have no clue which one is the authoritative one. So yes, it's a mess. But if you read the code in my rootstock-ng branch you'll understand that I'm not depending on the Ubuntu language packs feature: I need to deal with it since it's there, but my solution would work even if the traditional Ubuntu language packs were not there (and actually, it would work better).
What I'm doing is just taking the final rootfs and moving data out into clicks. It's a solution that works regardless of how translations end up in the rootfs in the first place.
As for question 2, when I was working in Canonical I made a change to account-polld (the service which gets invoked every 5 minutes in your device to check if you have new notifications for any of your accounts) and I rewrote it in order to allow third party developers to write plugins for it.
Plugins are in fact separate processes which communicate with the daemon via JSON messages (in a format similar to the one used by the push server), so they can be written in any language.
Unfortunately these changes got never merged into trunk, so if someone is making new images, please use the links above for building these components.
I'm willing to maintain and develop further these components in my spare time (same goes for the Online Accounts feature which I was maintaining in Ubuntu), so feel free to reach out to me in case you have questions on how to use them.
This channel would be useless to me and to many other developers, but if it brings benefits to halium developers, then why not. But then, why not call it "halium", "porters" or some other name that makes it clear what its target audience is?
"edge" to me means "more ahead than devel", but there's again the assumption that packages from this channel will eventually end up in "devel", "rc" and "stable"; so, I would suggest a different, more specific name.
I'm a happy owner of a YI 4K+ action camera, but unfortunately I haven't been able to use the livestreaming feature because it relies on a companion app which is only provided to Android and iOS users. Until today
I've uploaded a YI livestream app in the store which allows you to setup a livestream using any custom
rtmp URL. To make things more convenient, I've also integrated it with YouTube, so that you can create YouTube livestream directly from the app. I'll work on doing the same for VK — I myself use Facebook as little as possible, so I won't do the app for it (but if you have time to spare and want to contribute a patch, I won't refuse it!).
A demo video is also available.
I'm able now to download the repositories and the installation goes further and further.....until to throw an ultimate error complaining about broken packages. Here it is the new complete logfile:
You need to edit the
debian/control file of the project, and add a
<!nocheck> next to
xvfb, similarly to how it's done here. That's because this package is only used for running the tests, and tests are not run when using crossbuilder. You can do the same for the python packages.
After you manage to build the package with crossbuilder, it would be nice if you could create a pull request with your changes, so that the next contributor won't have to go through the same pain.
One important thing to have in order to make a developer's life easier (both app developers and ubports contributors) is an easy to use SDK. I think we'll later discuss about the various options, but one common trait which is needed to get good performance and reliability is being based on a single image (as opposed to retrieving thousands of debian packages via apt).
The SDK team at Canonical was preparing such images, and putting them online at https://sdk-images.canonical.com/, where the client SDK could retrieve them from. I would suggest that we continue doing the same (and possibly fix the bugs that occasionally are found on such images!) on our own servers, as I suspect that Canonical might shutdown that subdomain at any time. At the address above you can find the script which was used to generate the images; I already downloaded a copy of it, but maybe we should put it somewhere in github.
@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
I think that everyone would be happy with a notification server, if we were 100% sure that it was secure and that no one would have access to our notifications. Unfortunately, in real life this is very different to achieve.
Here's my brainstorming on the subject:
the notifications will be sent in encrypted form from then originating service (e.g., telegram) to the notification server. Only the ID of the destination user account will be left in clear (or encrypted with a key provided by the notification server), so that the notification server can read it and push the notification to the proper device. But the notification server should not have access to the contents of the notification, which will be encrypted in a way that only the destination device can decrypt.
if the option above is too difficult to implement, then I propose that the messages sent to the notification server should only contain the ID of the destination user: so, Telegram (for example) will inform the notification server that user X has something new, without specifying any further information. Then, the notification server will send a push notification to user X's device, telling it that there's something new in Telegram. The Telegram app will have to implement a push notification client consisting of a UI-less binary which will connect to the telegram servers, check what's new, and generate the JSON notification messages. If we plan this right, it should be possible to use the same binaries for this goal and for account-polld, which would make developers' life easier when switching between account-polld and the push notifications.
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.