As you have some work done with point 1 above, I am assigning this to @bshah. If you think this is more suited to someone else or don't have time, pass it on; or give it back to me when 1 is done.

For me, "Plasma Mobile" in the strict sense is a Plasma shell optimised for touch input. That's what the name implies, after all. Basically I see it as the successor to Plasma Active and the overall concept of Plasma adapting to one's hardware dynamically. Obviously for it to be useful there need to be other utilities that are touch optimised as well, but that's Plasma Mobile only in the loose sense (and actually KDE Applications). I find the other things (Kirigami etc.) to be their own projects that integrate well with the shell.

This was the easy part of this task. As per @IlyaBizyaev's comment:

Yeah, and we also probably need to ask developers fix most annoying issues there (i.e. those not present on real devices)

Yeah, I'm getting similar results from Twitter and G+.

In a day, the post on the Russian community page has collected 300 votes.
Here are the results:

Wow! Great job. That is what I call efficiency.

Just started a poll, it got widespread quickly. Hoping to get a lot of feedback.

Great. I am here too, so if you need any grunt-work done, just shout. Also, don't be afraid to recruit more people if you need them.

I hope so... It may be not the best time for me right now, but I'll be able to get this started.

Yes, sounds reasonable... Shall I assign this to you, @IlyaBizyaev, at least for the time being? Can you get this started?

As discussed, my points here are:

• To count contributors and set realistic goals, we need to define what Plasma Mobile is. Currently, I think of it as Halium (hardware abstraction), Kirigami as UI SDK, Plasma & whole stack as DE, some entry-level apps
• To be able to attract new contributors, we need to prepare for them internally: collect open tasks from participating projects; collect information on what devices can be used for testing already; prepare instructions for deployment and emulating
• Finally, to be able to promote Plasma Mobile, we need to know its strong points. As far as I know, it is far from being a daily driver, so we probably need to mention architectural strengths, design concepts, and wide opportunities

Resolved with Halium

It is not needed anymore.

Simple Login does not evaluate it. It should, or we should use sddm on the phone too.

Turns out this is normally sourced by XSetup a bash script we run our X sessions through.

Ideally SDDM should grow support for a wayland based greeter instead of a X11 greeter. This would involve looking at what XorgDisplayServer does and why the Greeter needs it.

/etc/profile.d gets evaluated by bash but not simplelogin. David needs to look into this to get it working.

see https://launchpadlibrarian.net/318291941/buildlog_ubuntu-xenial-armhf.flatpak_0.9.3-0alexlarsson2~xenial_BUILDING.txt.gz

Latest image solves the issue of QtQuick text rendering.

For investigating this issue, I tried to breakdown plasmashell into small parts till it stops breaking, initial thought was it is IconItem which is breaking the text. However it was false alarm as I missed two parts which were visible before my testcase (Keyboard and Lockscreen)

Regarding the amount of visible text: More like almost completely unfixed ;)

Not fixed completely.

Um. this doesn't got fixed with this.. reopening.

This was rather issue with selinux.. I thought selinux=0 is same as androidboot.selinux=permissive but it is not same apparently. Fixed.

This task is important for T4944 as well.. This would also be solved while adjustments required for T4944 is done.

I started working on it from last week, and currently the base android image based on the AOSP is working, now I need to make some adjustments in flashtool and we would be good to go.

This was one hell of issue with one-liner stupid mistake to fix..

what about a) just delete https://community.kde.org/Plasma/Mobile and start over, or
b) move all the chapters of that page as sub paragraphs of an ==OLD== paragraph and move them over just as needed?

non-programmatic way of finding it is,

Okay, at least this fixes some, but not all

Hopefully fixed with this.. Will close when is fixed for real.

This has been now fixed.

This seems to be fixed by doing,

This is fixed I suppose, there are still minor bugs in implementation, like close button showing when it should not, but that's different task

Currently xbuilder is not at all useful as some of the libraries, for instance wayland is not cross platform and results in the random failures during build time. I will also kill/archive xbuilder and xutils as this is no longer updated ever since we migrated to Xenial from Vivid. In general Plasma SDK is still required but, that needs to be separate task