Together with @jonius and @TimSueberkrueb, I had the great pleasure to build a small (about 250MB) MyCroft demo click package. Its at a very early stage: ssh server needs to be enabled on the device in order to use the app; its known to crash on FP2@16.04 and hammerhead@15.04 :-(but nonetheless you could try if its working on your FP2/nexus5) and is kind of working on turbo@15.04 and krillin@16.04 yippy Details on the status are found in the issue tracker. Everyones welcome to test it (obv)!

A little about how MyCroft works:

1. The device is listening for the wake word (atm) "Hey MyCroft". That is done locally on the device.
2. Everything said after the wake word is then sent to a speech to text web service. By default Googles is used.
3. The text returned is then mapped by the intent parser to a skill and depending on the skill different things will happen.
4. The skill returns text which is (locally) synthesized to speech again (also called text to speech).

A few sentences about privacy concerns and future plans:

1. To avoid having the microphone always on (beside privacy concerns it has an big impact on the battery too), it would be nice to wake MyCroft by pressing a hardware button. Whether this will be possible or not, depends on how it is integrated in/packaged for Ubuntu Touch.
2. Most probably it won't be possible to do the speech to text locally on the device. There will be a setting to select the service used (there are others than Google) but if you want to use it, you'll have to send your speech to some service at least or use a chat bot - @TimSueberkrueb is thinking about implementing this.
3. At the moment its funny in the first place. But my actual motivation having MyCroft, was for practical reasons: Being able to call mum while driving by car or adding milk to the buy list while baking... Therefor we have to interface with the apps (for example) and that of course should happen locally again, s.t. for the useful things only your verbal request (i.e. "call mum" or "add milk to the buy list") will be processed to text online and the rest will happen locally...

The issue tracker already also reflects these plans more or less. I'm very curious what you think about that and hope you enjoy testing.

@flohack @cibersheep so the background of the icon will be white right?
If it will be transparent you wont see any rounded corners anyway no matter if they are made automatically or not?
If the background will be white: could we see how it looks on a non white background? At best... just did it:

@domubpkm Now I have concrete news for you Heres Dekkos 0.2.0 release candidate:
https://gitlab.com/dekkan/dekko/-/jobs/298656006/artifacts/raw/build-armhf/dekko2.dekkoproject_0.2.0_armhf.click

I don't expect any more regression will come up, so that we will release it tomorrow or latest on Friday.

Status update:

• new alpha release here: https://gitlab.com/doniks/dekko/tags/0.1.6-alpha1
• python dependencies for the composer now included in the click (again)
• build process with clickable working fine now
• show stopper: Fails to display multi part mails (not html mails as told above)

So this isn't my work - only a very very very small part of it - but I would be very proud if it was mine and even reading the title of the thread doesn't feel right for me...
The only thing I can feel when holding dekko2 in my hands is deep gratefulness. Thank you Dan, for being with us, for continuing Dekko, making teleports possible and teaching and guiding us! Also thanks to all the other experienced developers as well as the not so experienced devolpers and also the non tech guys dedicating their time. And ofc thanks for all the donations. I especially like the way how the experienced people are guiding the unexperienced in the ubports community. Thats great! You're great!
@guru sry for hijacking your thread

Hi @domubpkm, two things to say:

1. the qtwebengine branch is where I left it off one month ago: oxide was replaced by qtwebengine in a clean way, but you won't be happy with the result, as the userscripts aren't working yet for some reason, causing
   • zooming to behave odd
   • the font being very tiny
   • context menu to not work

I think I will get back to it, after the next teleports release, and...

2. We fixed a date for the hackathon, it will take place on the 31. of August in Munich. There will be an official announcement as soon as the location is confirmed. Thanks to @jonius for organizing the hackathon!

The topic was once started by @mardy... He has already taken the very first steps, so he is the one to get in contact with...
Read also: https://github.com/ubports/address-book-app/issues/3
I don't think theres any code online now. It might be a good idea to open a telegram group for coordination. I would appreciate a hackathon on that topic...!

I'm very happy to announce, we have a beta version out. Get it here: https://gitlab.com/dekkan/dekko/tags/0.1.6-beta1

@PINE64 I really appreciate how open, realistic, trustable and reasonable PINE64 is acting! So here comes a bit of a delicate question, which I'm pretty sure is difficult to answer positively... For many of the people here (i guess) beside freedom, openness and privacy also acting responsible and ethically is important/an issue. Do you know how the Pine64 community thinks about that? Have their been any discussions/investigations on what it would cost to get a 'clean' supply chain or to what degree it would be even possible?
A few questions stolen from @lionelb:

• Does ethical manufacture have to mean that it is only affordable by an elite?
• Since you rely on many components, the research necessary to check green and labour credentials would be 10x the size of the rest of your organisation? (Would working together with the fairphone guys make sense?)
• Do you have some ethical policies and can we find them on the website or can you publish them?

Even if the outcome is that you use regular materials, as otherwise the price would skyrocket (@TheKit), I'm appreciating very much the possibility of having an honest discussion with you in contrast to almost all other companies...

Do you already know this: https://github.com/ubports/qqc2-suru-style/blob/master/qqc2-suru/qquicksurustyle.cpp?

So instead of defining only background colors you could suggest some sets of colors each containing all of the nine "input colors" and thus "defining a theme".

Then we maybe could add a third theme called "user defined" or "custom" and add a page to the settings app (or to UTTT) where the theme can be set and colors for the custom theme can be chosen. Your sets could act as some presets. The "best" one or two palettes could be dedicated themes maybe, and a "barrier free/color blind" theme/color preset would also be a cool thing.

Hi @lipkowski-be,

Dan Chapman (the maintainer of Dekko) is unavailable due to health issues... ;-( therefor any contribution to Dekko goes here https://gitlab.com/dekkan for now (since we can't merge them to master as long as Dan isn't around). Issues are still tracked in the original repo already posted by @advocatux: https://gitlab.com/dekkoproject/dekko/issues.
Also the webpage has gone down recently unfortunately... not sure if we will resurrect it, however we will continue to work on Dekko but progress will be much slower as long as Dan is unavailable. Up next: Dekko using qtwebengine to render mails instead of oxide - stay tuned.

Since there are popping up questions regarding email client from time to time, a short update on the state:
Actually we already had dekko 2 beta ready for upload to the openstore. But now we thinking of getting rid of oxcide first... @delijati already started working on this and has dekko 2 running prototypically without oxcide.
So expect dekko 2 to be in the openstore before/not after ota5 will be released.

First, please change your wording and try to be respectful.
Second, people who more or less know and trust the developers would agree to such things. There are some popular apps, where you can be pretty sure, they do no harm, but nonetheless the warning should be there. Also all the unconfined apps must be open source and are reviewed before they are published to the store.
Third: If an app is unconfined its usually to get around shortcomings of the system. Its really not nice, but that is how it is atm. Most people will prefer to have apps there with a warning over not having them available. Maybe a switch in the settings to hide unconfined apps would suit your needs?

I'm bad in using drawing programs, so i did a 5 minute sketch by hand, please don't laugh at me guys
I like your idea @Aury88 but maybe we want the logo to resemble the circle of friends a bit more? (Never forget where you came from...? ^^)

Would need to get the hands right in the middle...

@poVoq said in Nice article for beginner Python development on UT:

Just found this:
https://www.peterspython.com/en/blog/developing-ubuntu-touch-apps-with-python-using-pyotherside

Seems like a nice start

Also have a look at that:
https://github.com/timsueberkrueb/ubports-gettogether/blob/master/timsueberkrueb/pyotherside/presentation.md

Pyotherside will also work with qt quick controls 2?

Sure.

I have been in two hacker spaces lately. In the metalab in Vienna and in the shackspace in Stuttgart.
In both cases I had the strong feeling noone there uses UT. I'm really asking myself why these tech geeks who really seem to care for privacy are not using UT. For me they seem to be the perfect audience...
In the shackspace there is a door with a lot of stickers and they told me I could bring some if I wanted to. They also have a nice map at a wall showing a lot of hacker spaces using leds to indicate whether they are opened or not.
This all led me to the idea if we could somehow spread the word in all these hackerspaces. Maybe with talks and hands on events... What do you think?

The following core respectively system apps are currently unmaintained. (Or at least it seems so, no offense if you're the maintainer of one of these, just say beep ;))

Browser, contacts, music, weather, docviewer, gallery, messaging, mediaplayer, notes;

Who can imagine being the maintainer of one of these apps? Maintaining an app does not necessarily mean writing code, but I think at least understanding the code would be very helpful to manage and sort the issues.

Our core/system apps were very happy if they would find maintainers...

That is "as expected" and my "bad", if you want so... dekkan.dekko/Dekko 2 CE uses the old data from the dekkoproject.dekkos namespace in order to avoid that every user must setup their account again... Especially since theres no way to get mail that is older than some weeks (depending on how much mail you receive...) with newly setup accounts, I think this was actually a good decission. But this "hack" has some downsides also... like this one here... UT Tweak Tool and users are confused, as the data is not in the usual place and cleaning data with UT Tweak Tool does essentially nothing for Dekko 2 CE as it cleans the "wrong" directories...

If you want to have man pages in the terminal (which absolutely makes sense when thinking of convergence!) you could put them and man into ~/man respectively ~/bin manually and set the environment variable MANPATH or INFOPATH accordingly. Or make a click package for it which installs it to /opt/click.ubuntu.com/man.yourname/ and set PATH=/opt/click.ubuntu.com/man.yourname/current/bin and MANPATH=/opt/click.ubuntu.com/man.yourname/current/man or whatever in ~/.profile... That would be cool, I would install it too!

@flohack said in Dekko2 Developer Community Thread:

@hummlbach Do we have a small idea where the multipart problem could come from? Just asking to know if we should try to get more help rushing in

The status of the investigations concerning the multi part mails is, that dekko2 has a database in .cache/dekko2.dekkoproject/database/qmailstore.db to keep track of the mails. In that database it keeps the meta data and also the path to the file in which the actual mail is stored, for example: /home/phablet/.cache/dekko2.dekkoproject/mail/1534752857.4528.nEvJp. If its a multi part email theres a directory additionally, then called 1534752857.4528.nEvJp-parts with a file for each part. The directory is there also in xenial, but its empty, so the files for the parts are missing... So the next step is to investigate why dekkod fails to put the files there i think. I didn't get where dekkod puts his log yet... I had the impression, that its log messages do not end up in the usual place... I think i can solve this one soon, but even then, there are two other bugs waiting to get attention:

• a few html mails are not displayed properly
• some time dekko thinks that a single part message was multi part resulting in a crash

I actually "promised" (Rudi) to have dekko ready by end of august - thats seems to be a tough goal now... So depending on when we want/need to have dekko ready, you may want to get some more helping hands in:

@doniks said in Dekko2 Developer Community Thread:

... I'd say: Bring the cavalry!

hehe