Some Good News!!! Just wanted to let everyone know my interest is coming back (Canonical just landing us in the (some expletive here) really put me off for a while) .

Anyway I'm going to start working on getting the latest Dekko into the openstore for the legacy devices. It's going to take a few weeks at least to get there and it will most likely only have a subset of the current features as it is going to require a bit of a rework of the code. But you will be able to do all the basic mail management tasks.

Does anyone here have any objection to it being an unconfined app?

Once i've got some of the details ironed out I will set up a better location for discussing Dekko's features and plans going forward. As I will need as much input/ideas as possible. I don't think spamming the ubports forum is the right place for this.

In the recent restructuring of the project a new website has arisen, which you can find here. You will find links to the issue tracker, forum etc... so if you have any ideas, feature requests or want to get involved then head on over.

Ok so here my 2c...

I fully support the move to GitLab, but not for any real reason to do with Microsoft acquiring GitHub (although i do get others concerns). For me it's more about the project management aspect of UBports.

GitLab supports groups and subgroups so it's easier to organise our 300+ repositories, making it easier for everyone to find their way round, and also visualise the different parts of the project/platform and how they fit together. There could be groups for Unity8, System Apps, Core Apps, Packaging, Infra, Documentation, Tooling, Working Groups, Experimental... the possibilities are endless but each group is easy to digest and only contains repos specific to each groups goals. On GitHub you just get a giant list of all repos and you almost have to remember repo names as paginating through the list is just painful if you can't.

GitLab supports issues, milestones and kanban boards at both group and project level. This makes it really easy to organise per project as well as at the group level and get a higher level view of what's going on. You can also move issue between projects which is handy!.

GitLab CI would also be a great thing to have at the project level. Each project could define it's own pipeline for merge requests, doc generation, building and publishing clicks to open-store etc... and not have to use an external tool like TravisCI. Jenkins is probably still the right tool for the building ubports repo and could continue to build debs on changes to master, xenial, bionic branches. But allowing a project to define it's own pipeline, even attach their own hardware via a dedicated gitlab runner in my opinion is quite a powerful thing. Members of the community could even offer up spare hardware and create a pool of runners for UBports

GitLab releases new features nearly every month, so things can only get better.

GitHub is serving it's purpose right and doing the job ok, so it definitely doesn't need to be rushed if a decision is made to move.

Please note Dekko in the openstore is not ready for daily use, is still very much experimental and still very much geared towards being used on desktops. So please don't expect too much from it right now

p.s POP3 will be coming in the next update

@zubozrout something like this should work

$ docker run -it -v $PATH_TO_CLICK_DIR:/clickdir clickable/ubuntu-sdk:16.04-amd64 bash
$ apt install click-reviewers-tools
$ cd /clickdir
$ click-review my.click

@Phil-UK Dekko never stopped being developed or supported. Just the old code base was deprecated.

@aury88 No you can either create a Gitlab account or use an existing google, twitter, github or bitbucket account to sign-up/register

Rather than go forking Dekko, if someone sends me a patch that get's click support back in shape. We can see about doing a release. Just because I'm personally no longer supporting click, doesn't mean someone else can't jump in and take the baton on that side and keep up the support. Patches are always welcomed!

If you are just wanting to flash devices and not develop for them, then you should be fine using the UBports Installer on Debian. It is packaged as an AppImage

I'm not really sure what you are trying to achieve with this topic? Would you mind expanding on it a little more please?

Is your intention to document application development for unity8 / Ubuntu Touch?

Some notes:

Ubuntu "snaps" support any programming language as it's just a packaging format, and are not limited to what you have documented above. Also yaml and soap are not programming languages... one is a data serialization format for configuration files and the other is a protocol specification for structured data.

The HTML5 sdk hasn't been maintained for a couple of years now and shouldn't be considered an option unless somone wishes to bring it up to spec with the QML UI toolkit.

There is the Ubuntu React Native framework that web devs could use to bring there apps to Ubuntu https://github.com/CanonicalLtd/react-native/

You would need ~/.cache/dekko2.dekkoproject and ~/.local/share/dekko2.dekkoproject

Also for apps using pyotherside you no longer need to include pyotherside and libpython3.4m in your click package. These are now available in the rootfs, so make sure to remove them from your click before building for xenial.

@vandys The server guide to the push notification service is here which has example dbus calls. com.ubuntu.Postal.Post is the one you want. The postal service handles the popup notification, persistent notification entry in the messaging menu and adjusting the launcher count.

This is a bug in icloud. To get it to work you have to disable Dekko's use of the ID imap extension.

In ~/.config/*/dekko.dekkoproject.conf find the section for your icloud account and change the imap.extension.blacklist=QVariant() to imap.extension.blacklist=ID and then restart Dekko

@Mitu yes the UITK is still in use right now, and patches are still landing for it. But a move to using QQC2 is going to be the way forward. The UI is loaded as a plugin at runtime so UITK and QQC2 versions could be developed in parallel and share the backend (currently only messaging) with no major changes. So it's trivial to add a compile time option for which UI plugin to include.

The UITK version will always remain in the source tree, so anyone that wants to help carry that on is welcomed Or if Ubports moves to using a suru style for QQC2 (which is probably some way off, if at all) it should be quite easy to get Dekko working with that as well.

@hoh61 That's not correct. Applications are run exactly the same now as they were in the original ubuntu image. Just confined processes using apparmor. As you noted though there is an minimal android container which is the only usage of lxc (unless you install anbox).

I have a pull request for this ready here. Hopefully we are not too late to get it in for OTA-3

Could you please expand on "stand out a bit more"? as it's rather vague

@guru that 0.9.x click has never been released, is not supported and was never suggested that it worked. I would advise not to install it as it was only created to test specific features about a year ago and was not intended for use by users. But it seems to keep going around.

@pavejon have you enabled the "less secure apps" option in your google settings? https://support.google.com/accounts/answer/6010255?hl=en or if you use two factor authentication you can get an app specific password instead and use that to authenticate.