Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Martin Flöser]

Am 2017-09-05 12:10, schrieb Jonathan Riddell:

Also, fun bits happen, for example Debian updated your copyright in
the kwin package, Neon forgot to do that, but instead added other
copyright holders Debian missed. Also, Neon adds
"KF5IdleTimeKWinWaylandPrivatePlugin.so" to the kwin-common package,
while in Debian it's in kwin-wayland (where it belongs, I guess?).
Debian also builds proper debugsymbols using the dbgsym support in
Debian, while Neon is using legacy stuff.


Thanks for your bug reports, we also accept patches or bugs on
bugs.kde.org or KDE devs can commit directly :)


Before you start changing stuff: I think your packaging is correct here. 
The plugin gets loaded by kwin-core (which is part of kwin-common). The 
behavior with the plugin missing could become undefined any time the 
code changes and nobody would notice. So only packaging together with 
main_wayland as Debian does is dangerous :-)


Cheers
Martin

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Matthias Klumpp]

2017-09-05 12:10 GMT+02:00 Jonathan Riddell :
> On Mon, Sep 04, 2017 at 10:56:12PM +0200, Matthias Klumpp wrote:
>> > And honestly I don't think it's something the Debian team cares about: it's
>> > much more important to have the "perfect" package.
>>
>> Yes, that is required for getting things into the distribution. The
>> copyright analysis must be done and be good to even get into Debian,
>> which is something Neon was lacking last time I checked.
>
> There's nobody much watching over neon's copyright analysis so I often
> don't spend much time writing long copyright files. It's more
> important to me that the code KDE releases has clear and valid
> licences and I frequently make changes in KDE directly when it doesn't,
> as well as ensuring KDE projects actually make releases so they can
> get picked up by distros and that those releases follow a licence
> policy and best release practice plus defining those policies and best
> practice.

That makes complete sense for a project like Neon, which is
KDE-centric and wants to ship new version of KDEs software as soon as
possible.
Debian has a different focus there and treats all upstreams equal, in
equally not blindly trusting their license claims. That's why
copyright reviews are made and documented in d/copyright. Of course,
that's a pointless excercise if you *are* the upstream project :D

>> The Kubuntu
>> packaging oftentimes was mediocre too (bumping epochs without reason
>> comes to my mind, even for new packages) - *but* that is no reason to
>> take the Neon packaging, fix the problems and submit the changes back
>> to Neon and the package to Debian. That workflow would actually help
>> both projects and reduce work for Debian.
>
> I'm a bit lost here. epochs are typically set to keep package sets
> consistent with each other, you can blame stephan coolo for packaging
> KDE in debian in the 1990s. I'd love to have more sharing between
> kubuntu, neon and Debian. The neon packaging automatically merges in
> debian packaging for frameworks and makes it easy for everything else
> so I merge whenever there's a benefit.

I was specifically thinking about e.g. Muon getting an epoch although
it was a completely new package, etc. It's not really an obstacle for
collaboration though.

>> That got me curious, and I diff'ed the Neon vs. Debian packaging.
>> Surprisingly, the packaging is completely disjoint. Sometimes, Debian
>> is better, sometimes Neon is. And it looks like Neon does take care of
>> the copyright file afterall, in some packages it is even *better* than
>> in Debian.
>
> Why thank you, I think :)

>From just very briefly looking at the things, the Neon packaging is
often times better/more complete. I did not expect Neon to have a
better d/copyright file, so that was very surprising :-D

> We like to automate things in neon so the automated QA tools will moan
> about some thing which get fixed. It would be great if Debian and/or
> kubuntu would merge these back but I suspect it doesn't happen much.
>
> Stuff gets packaged on different schedules of course so updates happen at 
> different times.

Right - with Neon being faster, adopting changes in Debian would make
a lot of sense though, instead of duplicating effort.

>> Also, fun bits happen, for example Debian updated your copyright in
>> the kwin package, Neon forgot to do that, but instead added other
>> copyright holders Debian missed. Also, Neon adds
>> "KF5IdleTimeKWinWaylandPrivatePlugin.so" to the kwin-common package,
>> while in Debian it's in kwin-wayland (where it belongs, I guess?).
>> Debian also builds proper debugsymbols using the dbgsym support in
>> Debian, while Neon is using legacy stuff.
>
> Thanks for your bug reports, we also accept patches or bugs on
> bugs.kde.org or KDE devs can commit directly :)

Hehe ^^ - I think I'll fix that one directly then :-)

>> [...]
>> Anyway, this is something PureOS and Purism could actually resolve or
>> help resolving (in the ideal case directly on Debian, in the worst
>> case only for PureOS).
>
> Doing merges between neon/kubuntu/debian would be super awesome

I would love that! I am a member of the Debian KDE team, but the
majority of packaging work is not done by me, so I don't have that
much of a say about anything. But I could probably bring that up. The
primary person of contact about Debian KDE stuff would be maxy, I
think.
I think one of the best ways for collaboration would be merging the
Neon packaging autmatically into a branch of the corresponding Debian
packaging, so Debian can pick changes from there and ideally also send
patches back. Kubuntu was using a similar approach, but that was
stopped, so figuring out what went wrong there would likely be one of
the first things to do.

In any case, I think there is something we could do about making Neon
and KDE work better together. And also, I've put a task to investigate
fixing the Debian KDE task onto my todo list, because that one is
indeed not the 

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Jonathan Riddell]

On Mon, Sep 04, 2017 at 10:56:12PM +0200, Matthias Klumpp wrote:
> > And honestly I don't think it's something the Debian team cares about: it's
> > much more important to have the "perfect" package.
> 
> Yes, that is required for getting things into the distribution. The
> copyright analysis must be done and be good to even get into Debian,
> which is something Neon was lacking last time I checked.

There's nobody much watching over neon's copyright analysis so I often
don't spend much time writing long copyright files. It's more
important to me that the code KDE releases has clear and valid
licences and I frequently make changes in KDE directly when it doesn't,
as well as ensuring KDE projects actually make releases so they can
get picked up by distros and that those releases follow a licence
policy and best release practice plus defining those policies and best
practice.

> The Kubuntu
> packaging oftentimes was mediocre too (bumping epochs without reason
> comes to my mind, even for new packages) - *but* that is no reason to
> take the Neon packaging, fix the problems and submit the changes back
> to Neon and the package to Debian. That workflow would actually help
> both projects and reduce work for Debian.

I'm a bit lost here. epochs are typically set to keep package sets
consistent with each other, you can blame stephan coolo for packaging
KDE in debian in the 1990s. I'd love to have more sharing between
kubuntu, neon and Debian. The neon packaging automatically merges in
debian packaging for frameworks and makes it easy for everything else
so I merge whenever there's a benefit.

> That got me curious, and I diff'ed the Neon vs. Debian packaging.
> Surprisingly, the packaging is completely disjoint. Sometimes, Debian
> is better, sometimes Neon is. And it looks like Neon does take care of
> the copyright file afterall, in some packages it is even *better* than
> in Debian.

Why thank you, I think :)

We like to automate things in neon so the automated QA tools will moan
about some thing which get fixed. It would be great if Debian and/or
kubuntu would merge these back but I suspect it doesn't happen much.

Stuff gets packaged on different schedules of course so updates happen at 
different times.

> Also, fun bits happen, for example Debian updated your copyright in
> the kwin package, Neon forgot to do that, but instead added other
> copyright holders Debian missed. Also, Neon adds
> "KF5IdleTimeKWinWaylandPrivatePlugin.so" to the kwin-common package,
> while in Debian it's in kwin-wayland (where it belongs, I guess?).
> Debian also builds proper debugsymbols using the dbgsym support in
> Debian, while Neon is using legacy stuff.

Thanks for your bug reports, we also accept patches or bugs on
bugs.kde.org or KDE devs can commit directly :)

> > Just my 2 cents as someone who has been annoyed by the lack of collaboration
> > between Kubuntu and Debian for years

lo siento

> Anyway, this is something PureOS and Purism could actually resolve or
> help resolving (in the ideal case directly on Debian, in the worst
> case only for PureOS).

Doing merges between neon/kubuntu/debian would be super awesome

Jonathan

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Matthias Klumpp]

2017-09-04 22:29 GMT+02:00 Martin Flöser :
> Am 2017-09-04 19:51, schrieb Zlatan Todoric:
>>
>> I had pretty unstable experience with KDE in Debian, so I assume that
>> KDE community will improve that in future (we need more Debian KDE
>> maintainers!) ;)
>
> Personal opinion as a long time Debian testing user (~10 years) and KDE
> contributor following:
>
> The packaging of Debian is really not great and questionable. As an example:
> currently testing ships Qt 5.9 in combination with KWin 5.8. KWin 5.8 does
> not compile against Qt 5.9, patches exist in master and I refused to
> backport them to the 5.8 branch as that is untested. Debian shipped that
> without even consulting with upstream developers. I think that is extremely
> bad practice from a distribution. They know me, they know they could ask for
> my opinion.

That is definitely a problem. It could be that the team is overworked
though (I don't know enough here). In any case, a good relation with
upstream is key for any package maintainer, it looks like there is
definitely something lacking here.

> The task-kde does a really bad default package selection. As an example: it
> installs Konqueror as the default browser in the favorites section of the
> launcher while at the same time warning against QtWebKit based browsers in
> the release announcement.

Agreed! The KDE task interestingly isn't maintained by the KDE team
though, and last time I asked that there was no influence on it. I
doubt that. Sending a patch would definitely be accepted by the task
maintainers.
When we made Tanglu, people were amazed how well the distro was
working, and how quickly. When I looked into that, it turned out that
the more lightweight package selection was the biggest cause for that
perception.

> [...]
> And honestly I don't think it's something the Debian team cares about: it's
> much more important to have the "perfect" package.

Yes, that is required for getting things into the distribution. The
copyright analysis must be done and be good to even get into Debian,
which is something Neon was lacking last time I checked. The Kubuntu
packaging oftentimes was mediocre too (bumping epochs without reason
comes to my mind, even for new packages) - *but* that is no reason to
take the Neon packaging, fix the problems and submit the changes back
to Neon and the package to Debian. That workflow would actually help
both projects and reduce work for Debian.
But I think this is getting into a highly political area, and I don't
feel qualified to comment about why things are the way they are or
what has been tried in the past.

> After all they constantly
> re-invent the wheel instead of using the already packaged software by
> Kubuntu or KDE Neon (hopefully that improved, but looking at the recent
> commits it doesn't look like it:
> https://anonscm.debian.org/git/pkg-kde/plasma/kwin.git/commit/?id=1cf72f55228a59fb37649c8f8a29cc509a8881b1
> ).

That got me curious, and I diff'ed the Neon vs. Debian packaging.
Surprisingly, the packaging is completely disjoint. Sometimes, Debian
is better, sometimes Neon is. And it looks like Neon does take care of
the copyright file afterall, in some packages it is even *better* than
in Debian.
Also, fun bits happen, for example Debian updated your copyright in
the kwin package, Neon forgot to do that, but instead added other
copyright holders Debian missed. Also, Neon adds
"KF5IdleTimeKWinWaylandPrivatePlugin.so" to the kwin-common package,
while in Debian it's in kwin-wayland (where it belongs, I guess?).
Debian also builds proper debugsymbols using the dbgsym support in
Debian, while Neon is using legacy stuff.

> Just my 2 cents as someone who has been annoyed by the lack of collaboration
> between Kubuntu and Debian for years

>From briefly looking over it, I have to agree - this is not only slightly 
>mad...
I know at some point, Kubuntu packaging was in Debian Git, but then it
was abandoned (I think someone in Debian complained, but I am not
certain).

Anyway, this is something PureOS and Purism could actually resolve or
help resolving (in the ideal case directly on Debian, in the worst
case only for PureOS).

Cheers,
Matthias

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Martin Flöser]

Am 2017-09-04 19:51, schrieb Zlatan Todoric:

I had pretty unstable experience with KDE in Debian, so I assume that
KDE community will improve that in future (we need more Debian KDE
maintainers!) ;)


Personal opinion as a long time Debian testing user (~10 years) and KDE 
contributor following:


The packaging of Debian is really not great and questionable. As an 
example: currently testing ships Qt 5.9 in combination with KWin 5.8. 
KWin 5.8 does not compile against Qt 5.9, patches exist in master and I 
refused to backport them to the 5.8 branch as that is untested. Debian 
shipped that without even consulting with upstream developers. I think 
that is extremely bad practice from a distribution. They know me, they 
know they could ask for my opinion.


The task-kde does a really bad default package selection. As an example: 
it installs Konqueror as the default browser in the favorites section of 
the launcher while at the same time warning against QtWebKit based 
browsers in the release announcement.


When I install Debian it looks to me like a try to package everything 
and provide everything. But not like trying to get a decent desktop 
experience. If you compare that to openSUSE or KDE Neon - that are huge 
differences.


And honestly I don't think it's something the Debian team cares about: 
it's much more important to have the "perfect" package. After all they 
constantly re-invent the wheel instead of using the already packaged 
software by Kubuntu or KDE Neon (hopefully that improved, but looking at 
the recent commits it doesn't look like it: 
https://anonscm.debian.org/git/pkg-kde/plasma/kwin.git/commit/?id=1cf72f55228a59fb37649c8f8a29cc509a8881b1 
).
If you literally waste time like that, it's no surprise the quality 
suffers :-(


Just my 2 cents as someone who has been annoyed by the lack of 
collaboration between Kubuntu and Debian for years


Cheers
Martin

Re: Plasma Mobile on the Librem 5

[Zlatan Todoric]

Hi Martin,


On 09/04/2017 06:00 PM, Martin Flöser wrote:
> Am 2017-09-03 23:17, schrieb Sebastian Kügler:
>> I do know that there is a good amount of interest
>> in the community, but my impression is also that many people are
>> playing a waiting game for others to move before they're getting their
>> hands dirty. This is something we need to resolve to get the ball really
>> rolling. A decent plan and coordination of these effort is definitely
>> needed, and this is something we should come up with first. Build and
>> they will come.
>
> *nod* - I absolutely think this is a chicken-egg problem. Due to not
> having hardware nobody is interested in doing work and due to not
> having software we don't get the hardware. Librem 5 might be just the
> push to get out of this loop. What might be needed is getting
> development boards early to KDE devs and we need to get the initial
> setup story good, so that it's easy to hack on without having to fight
> the system (I remember the horror of Nokia's maemo cross compiler)
>
>>> Now that is said - what suggestion do you have for a meeting around
>>> promoting collaboration between Purism and KDE regarding Librem5?
>>> Videoconferencing or async via mail? Other tools? I would add to the
>>> discussion our CEO, CMO and Director of Creative.
>>
>> Video would probably work best, a phone conference is also an option.
>> Plasma and KDE promo people are mostly in Europe, but I'm sure we can
>> make something work, even if it's outside of office hours (I don't
>> mind).
>
> If you need any input from the Wayland stack (e.g. rendering, input)
> I'm happy to participate, though that would mean outside of office
> hours ;-) (earliest 16 CEST).

You should participate for sure as I plan to have Wayland as the only
display server we will run (if we can avoid X and all its dependencies,
that would be a good thing for all). I will now create a separate thread
for the proposal of meeting date.

>
> Cheers
> Martin
Z

Re: Plasma Mobile on the Librem 5

[Zlatan Todoric]

On 09/03/2017 11:17 PM, Sebastian Kügler wrote:
> Hey Zlatan,
>
> On Sat, 2 Sep 2017 17:23:09 +0200
> Zlatan Todoric  wrote:
>
>> (Cleared all previous mails to make this one more visible, feel free
>> to respond on this one while quoting previous replies in this thread)
>>
>> Hi all,
>>
>> so I had discussion with our CEO and he is of course absolutely in.
>> To make clear our standpoint - both GNOME and KDE *will* be first
>> class citizen on Librem5. So there is no favorite between two, but
>> both are equal in this challenge.
>>
>> That said, looking in general code readiness between two, it would
>> appear that plasma mobile would be default in first wave of librems
>> (we are not releasing until one DE is ready for it and we will also
>> not wait for other DE to be ready but gradually add it). There is
>> some discussion in terms of offer - do we want to offer Librem5 with
>> choice of having Plasma or GNOME or do we have both right away inside
>> (maybe to heavy for such device)  so users can pick during boot-up?
> I'm not familiar with GNOME's strategy for a mobile UI (would love to
> know more however!), so for me it's hard to judge whether Plasma is
> technologically closer. From the Plasma side, I know that we're
> *currently* not good enough for anything end-user, so it will need a
> dedicated development push, and we need to rally the resources
> necessary for that. I do know that there is a good amount of interest
> in the community, but my impression is also that many people are
> playing a waiting game for others to move before they're getting their
> hands dirty. This is something we need to resolve to get the ball really
> rolling. A decent plan and coordination of these effort is definitely
> needed, and this is something we should come up with first. Build and
> they will come.

GNOME is basically not ready at all. The GTK3 is not for mobile use and
it will not get any updates regarding that (it is considered stable, in
frozen state and they don't want to break ABI). GTK4 has potential to be
mobile ready toolkit but that can be a year or two away and someone
would still need to write entire UI for it.

I heard about the issue of plasma mobile community not having energy to
push things forward as they didn't have the device for it but now we
have a chance to finally have device and not play at all in Android
world and all the hassle those devices bring with for developing Free OS.

>
> On the other hand, the offering of non-Android Free software mobile
> workspaces and apps have, with the demise of Firefox OS and Ubuntu
> become pretty thin, and the best we can hope from that rather
> disappointing development is that a consolidation will bundle
> resources and get the community together with more focus. 

Yep, I hope we will get campaign out, so we can revive entire community
around it and create collaboration and growth that will connect all dots
for entire community (I consider Purism just as part of larger
community) so we can create something unique and break status quo.

>
>> Also, while currently we are offering PureOS with GNOME as default on
>> Librem13/15, I think there is future for KDE as desktop offering by
>> default as well (also as an option PureOS GNOME and PureOS Plasma/KDE)
>> because the convergence might be very interesting choice for many
>> users and your desktop is very modular for fine tweaking.
> I haven't looked into the packaging for the device, so it's hard to
> comment on that. I can imagine that Plasma is something people would
> want to run on the device, and it makes a story of complementary
> devices both running Plasma more compelling, so I think we should at
> least have an answer to that.

PureOS is basically Debian - and I as Purism CTO and as Debian Developer
invite entire community to help make KDE as best as possible for user
experience.

>
> That said, I'm not familiar with packaging for PureOS, and KDE is just
> getting ready to flatpak things. I'm not sure in how far flatpacking
> the DE is an option, but I guess Matthias can weigh in here as well. We
> do have some expertise in the Plasma team as well, but so far the DE
> itself hasn't been the primary target of our flatpak efforts, we've
> more concentrated on apps. I'd be interesting to know, perhaps we can
> use the Librem notebooks as potential targets when we think about how we
> want to make deployment of Plasma possible. I suppose it's a good way
> to get Plasma ready for deployment on the handheld devices as well.
> These kind of deployment scenarios are actually at the heart of
> Plasma's cross device strategy, so I'd love to find out more.

Flatpak'ing DE is not something you should do. Flatpaks are meant for
graphical apps. I think the best possible combination for wider
community is to have base OS and base DE components as .deb's and have
upstream make flatpak of their end-user apps. For OS/DE security we plan
to enable AppArmor as default because in my 

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Matthias Klumpp]

2017-09-04 19:51 GMT+02:00 Zlatan Todoric :
> [...]
> Well, for having both as separate offer (if GNOME hits the pace), is not
> an issue. I am wondering if having both at the same time on phone will
> end up being to much (how many libraries are there that one uses and
> other DE doesn't), also depending on disk space, you don't want to eat
> like 20% of all space for base OS.

Just commenting on that point: I think having two DEs on a phone with
some kind of "desktop switcher" is a terrible idea. I think it would
be much more maintainable if we spin two separate base images, and in
case someone wants something different they can just swap those (we
will offer those images on our website anyway).

Giving users the choice to switch between desktops randomly when using
the phone is a bad thing usability wise (it's not a simple thing, and
radically changes the appearance of the UI), requires additional
engineering effort and is generally harder to maintain and support
(because we will have multiple configurations and mix of technology on
one image).
Shipping the phone with one default image and offering others on our
site that people can put on their phone seems to be a much better idea
to me.

> I had pretty unstable experience with KDE in Debian, so I assume that
> KDE community will improve that in future (we need more Debian KDE
> maintainers!) ;)

When exactly was that? ;-) But yeah, the Debian KDE team would be
happy for any additional help.

> [...]

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Zlatan Todoric]

Hey Thomas,


On 09/03/2017 02:16 AM, Thomas Pfeiffer wrote:
> Hi Zlatan,
> please ignore my previous two mails mail to you which were both sent
> from the wrong address (sorry for that, new computer with no proper
> email client yet and GMail is terrible when it comes to multiple email
> addresses).

heh, no worries.

> On Sat, Sep 2, 2017 at 5:23 PM, Zlatan Todoric  wrote:
>> (Cleared all previous mails to make this one more visible, feel free to
>> respond on this one while quoting previous replies in this thread)
>>
>> Hi all,
>>
>> so I had discussion with our CEO and he is of course absolutely in.
> Great to hear!
>
>> To make clear our standpoint - both GNOME and KDE *will* be first class
>> citizen on Librem5. So there is no favorite between two, but both are
>> equal in this challenge.
>> That said, looking in general code readiness between two, it would
>> appear that plasma mobile would be default in first wave of librems (we
>> are not releasing until one DE is ready for it and we will also not wait
>> for other DE to be ready but gradually add it).
> Makes sense.
>
>> There is some discussion
>> in terms of offer - do we want to offer Librem5 with choice of having
>> Plasma or GNOME or do we have both right away inside (maybe to heavy for
>> such device)  so users can pick during boot-up?
> Sounds like quite a challenge, but if you can make it work, why not?

Well, for having both as separate offer (if GNOME hits the pace), is not
an issue. I am wondering if having both at the same time on phone will
end up being to much (how many libraries are there that one uses and
other DE doesn't), also depending on disk space, you don't want to eat
like 20% of all space for base OS.

>
>> Also, while currently we are offering PureOS with GNOME as default on
>> Librem13/15, I think there is future for KDE as desktop offering by
>> default as well (also as an option PureOS GNOME and PureOS Plasma/KDE)
>> because the convergence might be very interesting choice for many users
>> and your desktop is very modular for fine tweaking.
> Great to hear that as well, and of course we agree that Plasma Desktop
> and Plasma Mobile work great in tandem!

I had pretty unstable experience with KDE in Debian, so I assume that
KDE community will improve that in future (we need more Debian KDE
maintainers!) ;)

>
>> Now that is said - what suggestion do you have for a meeting around
>> promoting collaboration between Purism and KDE regarding Librem5?
>> Videoconferencing or async via mail? Other tools? I would add to the
>> discussion our CEO, CMO and Director of Creative.
> Yes, that's certainly useful!
> Video conference sounds good since it's always nice to see people when
> getting to know them. Which system do you usually use for video calls?
> We've been using Jitsi Meet or OpenTokRTC so far.
>
> From our side apart from Sebastian it would be Bhushan (Plasma
> Mobile's maintainer), Paul from the KDE promo team, me (Thomas, member
> of the board of directors of KDE e.V. and member of KDE's design
> team), and potentially others who might want to join.

Everyone is welcome!

>
> What times would work best for you?

I will write separate mail to propose time after I answer few more mails
in this thread.

>
> Looking forward to the meeting,
> Thomas
Z (excited as well)

Re: Plasma Mobile on the Librem 5

[Martin Flöser]

Am 2017-09-03 23:17, schrieb Sebastian Kügler:

I do know that there is a good amount of interest
in the community, but my impression is also that many people are
playing a waiting game for others to move before they're getting their
hands dirty. This is something we need to resolve to get the ball 
really

rolling. A decent plan and coordination of these effort is definitely
needed, and this is something we should come up with first. Build and
they will come.


*nod* - I absolutely think this is a chicken-egg problem. Due to not 
having hardware nobody is interested in doing work and due to not having 
software we don't get the hardware. Librem 5 might be just the push to 
get out of this loop. What might be needed is getting development boards 
early to KDE devs and we need to get the initial setup story good, so 
that it's easy to hack on without having to fight the system (I remember 
the horror of Nokia's maemo cross compiler)



Now that is said - what suggestion do you have for a meeting around
promoting collaboration between Purism and KDE regarding Librem5?
Videoconferencing or async via mail? Other tools? I would add to the
discussion our CEO, CMO and Director of Creative.


Video would probably work best, a phone conference is also an option.
Plasma and KDE promo people are mostly in Europe, but I'm sure we can
make something work, even if it's outside of office hours (I don't
mind).


If you need any input from the Wayland stack (e.g. rendering, input) I'm 
happy to participate, though that would mean outside of office hours ;-) 
(earliest 16 CEST).


Cheers
Martin

Re: Plasma Mobile on the Librem 5

[Eike Hein]

On 08/30/2017 10:31 PM, Matthias Klumpp wrote:
> I was made aware of that effort already a few weeks ago, and it is
> looking great! I guess the default Matrix app in the Librem phone
> would have to be something focused on person-to-person communication
> and tight integration with the user's contact list, instead of being
> more group-chat centric like Konversation is. But having more choice
> in Matrix clients is a good thing, and maybe we can have different UIs
> for the same backend.

Indeed!

Having worked on chat and related stuff for some time, we're no
stranger to trying to provide rich integration in that space.

Once upon a time in KDE 3, we had a technology called "KIMProxy" -
KMail was able to tell you when the sender of an email was online
in Konversation on IRC while you were reading their mail, as both
drew upon the same address book, with Konversation allowing to
associate IRC nicks with address book contacts and contributing
presence state to a global pool. Our instant messenger application
at the time, Kopete, was likewise integrated with the system.

In Plasma 5 we currently have a successor technology called KPeople,
which is used in concert with KDE Telepathy, the KActivities(-Stats)
framework and the launcher menu backend. The launcher menus bundled
with Plasma Desktop have an optional "Recent Contacts" category
which will list recent conversations by contact, with realtime
presence status (i.e. a little online status badge on the contact
avatar used as icon for the menu entry).

This works by KDE Telepathy providing a KPeople plugin that contri-
butes data (contact info, state) to the pool and entering KPeople
URIs to the KActivities-Stats db when opening a conversation. The
launcher menu backend queries the db, and then uses KPeople API to
get contact info and state - without knowing anything about KDE
Telepathy specifically.

The plan would be for Konversation's Matrix backend to likewise
integrate with KPeople, getting that info into the launchers.

This is relevant for Plasma Mobile as we have plans to reimple-
ment the homescreen UI on top of the Plasma Desktop launcher
menu backend - it provides all the apps/docs/contacts/widgets
data it needs along with a rich favoriting mechanism (i.e.
pinning things). The Application Dashboard fullscreen launcher
bundled with Plasma Desktop probably drives this possibility
home the best right now.

Retaining KPeople, PM's Contacts application would then likewise
be written against its APIs.

This is all stuff we have in some sense done before, know how to
do, and know we want ... :)


Cheers,
Eike
-
Plasma, apps developer
KDE e.V. vice president, treasurer

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-09-03 23:17 GMT+02:00 Sebastian Kügler :
> Hey Zlatan,
> [...]
>> so I had discussion with our CEO and he is of course absolutely in.
>> To make clear our standpoint - both GNOME and KDE *will* be first
>> class citizen on Librem5. So there is no favorite between two, but
>> both are equal in this challenge.
>>
>> That said, looking in general code readiness between two, it would
>> appear that plasma mobile would be default in first wave of librems
>> (we are not releasing until one DE is ready for it and we will also
>> not wait for other DE to be ready but gradually add it). There is
>> some discussion in terms of offer - do we want to offer Librem5 with
>> choice of having Plasma or GNOME or do we have both right away inside
>> (maybe to heavy for such device)  so users can pick during boot-up?
>
> I'm not familiar with GNOME's strategy for a mobile UI (would love to
> know more however!), so for me it's hard to judge whether Plasma is
> technologically closer. From the Plasma side, I know that we're
> *currently* not good enough for anything end-user, so it will need a
> dedicated development push, and we need to rally the resources
> necessary for that.

Plasma is much further developed than GNOME though on the mobile front
- GNOME at the moment would require a vendor to commit to making GNOME
Mobile, which is a rather large task involving changes in all parts of
the GNOME platform. Plasma Mobile on the other hand has the groundwork
done already.

> I do know that there is a good amount of interest
> in the community, but my impression is also that many people are
> playing a waiting game for others to move before they're getting their
> hands dirty. This is something we need to resolve to get the ball really
> rolling. A decent plan and coordination of these effort is definitely
> needed, and this is something we should come up with first. Build and
> they will come.

Indeed!

> [...]
>> Also, while currently we are offering PureOS with GNOME as default on
>> Librem13/15, I think there is future for KDE as desktop offering by
>> default as well (also as an option PureOS GNOME and PureOS Plasma/KDE)
>> because the convergence might be very interesting choice for many
>> users and your desktop is very modular for fine tweaking.
>
> I haven't looked into the packaging for the device, so it's hard to
> comment on that. I can imagine that Plasma is something people would
> want to run on the device, and it makes a story of complementary
> devices both running Plasma more compelling, so I think we should at
> least have an answer to that.
>
> That said, I'm not familiar with packaging for PureOS, and KDE is just
> getting ready to flatpak things.

Don't worry about that - PureOS is basically a combination of Debian
with things the FSF doesn't like stripped out, combined with some good
ideas from the Tanglu debian derivative. Anything that runs on Debian
runs on PureOS as well.

> I'm not sure in how far flatpacking
> the DE is an option, but I guess Matthias can weigh in here as well.

Flatpacking a DE is a bad idea. Flatpak is strictly for applications,
and does not work well (or at all, depending on the specifics) for
anything that's more than an app. For example, the desktop needs to
provide the portals implementation, fire up the user/session DBus on
startup, communicate with the display manager, and in general
integrate well with the rest of the OS. It also doesn't benefit much
from being sandboxed, since it launches applications that would
inherit the sandboxing policies of their parent, which can cause all
kind of problems.

For the phone base system, I envision a system similar to what
EndlessOS[1] currently is. This will require quite a bit of
redesigning of PureOS to work well with OSTree[2] and build OSTree
images automatically from packages, but will work much better on a
phone. Apps should be in Flatpaks, but that is also something I can
help with (although last time I looked at it, all work was done in KDE
already).
In any case, don't worry about the base OS and plumbing layer for now
:-) That will work well no matter which UX sits on top.

> We
> do have some expertise in the Plasma team as well, but so far the DE
> itself hasn't been the primary target of our flatpak efforts, we've
> more concentrated on apps.

Don't try flatpacking the DE, it won't be a good investment of time
(Ubuntu's Snappy system works differently here in that it allows
making snaps of pretty much anything, even system components - last
time I heard though that even Ubuntu would stick with .deb package for
longer though).
Flatpak is strictly for apps, and at the moment even more strictly for
apps that have a graphical user interface.

> [...]

Cheers,
Matthias

Re: Plasma Mobile on the Librem 5

[Sebastian Kügler]

Hey Zlatan,

On Sat, 2 Sep 2017 17:23:09 +0200
Zlatan Todoric  wrote:

> (Cleared all previous mails to make this one more visible, feel free
> to respond on this one while quoting previous replies in this thread)
> 
> Hi all,
> 
> so I had discussion with our CEO and he is of course absolutely in.
> To make clear our standpoint - both GNOME and KDE *will* be first
> class citizen on Librem5. So there is no favorite between two, but
> both are equal in this challenge.
> 
> That said, looking in general code readiness between two, it would
> appear that plasma mobile would be default in first wave of librems
> (we are not releasing until one DE is ready for it and we will also
> not wait for other DE to be ready but gradually add it). There is
> some discussion in terms of offer - do we want to offer Librem5 with
> choice of having Plasma or GNOME or do we have both right away inside
> (maybe to heavy for such device)  so users can pick during boot-up?

I'm not familiar with GNOME's strategy for a mobile UI (would love to
know more however!), so for me it's hard to judge whether Plasma is
technologically closer. From the Plasma side, I know that we're
*currently* not good enough for anything end-user, so it will need a
dedicated development push, and we need to rally the resources
necessary for that. I do know that there is a good amount of interest
in the community, but my impression is also that many people are
playing a waiting game for others to move before they're getting their
hands dirty. This is something we need to resolve to get the ball really
rolling. A decent plan and coordination of these effort is definitely
needed, and this is something we should come up with first. Build and
they will come.

On the other hand, the offering of non-Android Free software mobile
workspaces and apps have, with the demise of Firefox OS and Ubuntu
become pretty thin, and the best we can hope from that rather
disappointing development is that a consolidation will bundle
resources and get the community together with more focus. 

> Also, while currently we are offering PureOS with GNOME as default on
> Librem13/15, I think there is future for KDE as desktop offering by
> default as well (also as an option PureOS GNOME and PureOS Plasma/KDE)
> because the convergence might be very interesting choice for many
> users and your desktop is very modular for fine tweaking.

I haven't looked into the packaging for the device, so it's hard to
comment on that. I can imagine that Plasma is something people would
want to run on the device, and it makes a story of complementary
devices both running Plasma more compelling, so I think we should at
least have an answer to that.

That said, I'm not familiar with packaging for PureOS, and KDE is just
getting ready to flatpak things. I'm not sure in how far flatpacking
the DE is an option, but I guess Matthias can weigh in here as well. We
do have some expertise in the Plasma team as well, but so far the DE
itself hasn't been the primary target of our flatpak efforts, we've
more concentrated on apps. I'd be interesting to know, perhaps we can
use the Librem notebooks as potential targets when we think about how we
want to make deployment of Plasma possible. I suppose it's a good way
to get Plasma ready for deployment on the handheld devices as well.
These kind of deployment scenarios are actually at the heart of
Plasma's cross device strategy, so I'd love to find out more.

> Now that is said - what suggestion do you have for a meeting around
> promoting collaboration between Purism and KDE regarding Librem5?
> Videoconferencing or async via mail? Other tools? I would add to the
> discussion our CEO, CMO and Director of Creative.

Video would probably work best, a phone conference is also an option.
Plasma and KDE promo people are mostly in Europe, but I'm sure we can
make something work, even if it's outside of office hours (I don't
mind). 

Cheers,
-- 
sebas

http://vizZzion.org   ⦿http://www.kde.org

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Thomas Pfeiffer]

Hi Zlatan,
please ignore my previous two mails mail to you which were both sent
from the wrong address (sorry for that, new computer with no proper
email client yet and GMail is terrible when it comes to multiple email
addresses).

On Sat, Sep 2, 2017 at 5:23 PM, Zlatan Todoric  wrote:
> (Cleared all previous mails to make this one more visible, feel free to
> respond on this one while quoting previous replies in this thread)
>
> Hi all,
>
> so I had discussion with our CEO and he is of course absolutely in.

Great to hear!

> To make clear our standpoint - both GNOME and KDE *will* be first class
> citizen on Librem5. So there is no favorite between two, but both are
> equal in this challenge.

> That said, looking in general code readiness between two, it would
> appear that plasma mobile would be default in first wave of librems (we
> are not releasing until one DE is ready for it and we will also not wait
> for other DE to be ready but gradually add it).

Makes sense.

>There is some discussion
> in terms of offer - do we want to offer Librem5 with choice of having
> Plasma or GNOME or do we have both right away inside (maybe to heavy for
> such device)  so users can pick during boot-up?

Sounds like quite a challenge, but if you can make it work, why not?

> Also, while currently we are offering PureOS with GNOME as default on
> Librem13/15, I think there is future for KDE as desktop offering by
> default as well (also as an option PureOS GNOME and PureOS Plasma/KDE)
> because the convergence might be very interesting choice for many users
> and your desktop is very modular for fine tweaking.

Great to hear that as well, and of course we agree that Plasma Desktop
and Plasma Mobile work great in tandem!

> Now that is said - what suggestion do you have for a meeting around
> promoting collaboration between Purism and KDE regarding Librem5?
> Videoconferencing or async via mail? Other tools? I would add to the
> discussion our CEO, CMO and Director of Creative.

Yes, that's certainly useful!
Video conference sounds good since it's always nice to see people when
getting to know them. Which system do you usually use for video calls?
We've been using Jitsi Meet or OpenTokRTC so far.

>From our side apart from Sebastian it would be Bhushan (Plasma
Mobile's maintainer), Paul from the KDE promo team, me (Thomas, member
of the board of directors of KDE e.V. and member of KDE's design
team), and potentially others who might want to join.

What times would work best for you?

Looking forward to the meeting,
Thomas

Re: Plasma Mobile on the Librem 5

[Zlatan Todoric]

(Cleared all previous mails to make this one more visible, feel free to
respond on this one while quoting previous replies in this thread)

Hi all,

so I had discussion with our CEO and he is of course absolutely in.
To make clear our standpoint - both GNOME and KDE *will* be first class
citizen on Librem5. So there is no favorite between two, but both are
equal in this challenge.

That said, looking in general code readiness between two, it would
appear that plasma mobile would be default in first wave of librems (we
are not releasing until one DE is ready for it and we will also not wait
for other DE to be ready but gradually add it). There is some discussion
in terms of offer - do we want to offer Librem5 with choice of having
Plasma or GNOME or do we have both right away inside (maybe to heavy for
such device)  so users can pick during boot-up?

Also, while currently we are offering PureOS with GNOME as default on
Librem13/15, I think there is future for KDE as desktop offering by
default as well (also as an option PureOS GNOME and PureOS Plasma/KDE)
because the convergence might be very interesting choice for many users
and your desktop is very modular for fine tweaking.

Now that is said - what suggestion do you have for a meeting around
promoting collaboration between Purism and KDE regarding Librem5?
Videoconferencing or async via mail? Other tools? I would add to the
discussion our CEO, CMO and Director of Creative.

Happy hacking,
Z

Re: Plasma Mobile on the Librem 5

[Zlatan Todoric]

On 08/31/2017 11:21 AM, Sebastian Kügler wrote:
> > > 2017-08-29 16:44 GMT+02:00 Sebastian Kügler :
> > >> Would it make sense to get together and look at Plasma Mobile and
> > >> Purism's plans, and devise a possible strategy and next steps? Maybe
> > >> get together in a video conference with everybody interested in this
> > >> project, and see how we can work out common ground and plans, and how
> > >> we can kick things off?
>
> > On 08/30/2017 03:43 PM, Matthias Klumpp wrote:
> > > I would like that a lot, I think it's a good way forward.
> > > @Zlatan, what do you think?
> > > We would need to have a bit of internal discussion first though, and
> > > maybe need to wait for the campaign to succeed first.
>
> On woensdag 30 augustus 2017 20:22:16 CEST Zlatan Todoric wrote:
> > Absolutely agree, that once we have successful campaign (otherwise we
> > are without device and on ground zero again), we should (and in this
> > case we will) sit down with KDE community and discuss the effort forward
> > in detail as I am also internally proponent of plasma-mobile readiness
> > compare to current GNOME stack.
>
> For technical things, absolutely.
>
> Campaign promotion also is something KDE can help with. I discussed this
> project internally with a few people, and various people in our
> community,
> also in our "marketing and promo department" are enthusiastic to a
> point where
> they'd like to support the campaign by tapping into users dreaming of
> a Free
> device running Plasma Mobile. One idea that floated around was a video
> showing
> some possibilities and ideas.
>
> Something like this should happen together with Purism, though, as
> that would
> strengthen the message, prevent communication problems and make
> expectations
> management easier (we surely don't want to leave backers or other people
> disappointed).
>
> Who should we talk about joint promo with within Purism?

With me is enough, I can add our creative person (Francois) who is doing
promo material (including videos) in Purism if that will help.

I love the idea, so whenever you're (KDE team) are ready, let us know
and we will schedule meeting (I'll see to include CEO in the meeting as
well).

Looking forward to community collaboration and pushing our dream forward
with new and innovative ecosystem \o/

Happy hacking,
Z

Re: Plasma Mobile on the Librem 5

[Sebastian Kügler]

> > 2017-08-29 16:44 GMT+02:00 Sebastian Kügler :
> >> Would it make sense to get together and look at Plasma Mobile and
> >> Purism's plans, and devise a possible strategy and next steps? Maybe
> >> get together in a video conference with everybody interested in this
> >> project, and see how we can work out common ground and plans, and how
> >> we can kick things off?

> On 08/30/2017 03:43 PM, Matthias Klumpp wrote:
> > I would like that a lot, I think it's a good way forward.
> > @Zlatan, what do you think?
> > We would need to have a bit of internal discussion first though, and
> > maybe need to wait for the campaign to succeed first.

On woensdag 30 augustus 2017 20:22:16 CEST Zlatan Todoric wrote:
> Absolutely agree, that once we have successful campaign (otherwise we
> are without device and on ground zero again), we should (and in this
> case we will) sit down with KDE community and discuss the effort forward
> in detail as I am also internally proponent of plasma-mobile readiness
> compare to current GNOME stack.

For technical things, absolutely.

Campaign promotion also is something KDE can help with. I discussed this 
project internally with a few people, and various people in our community, 
also in our "marketing and promo department" are enthusiastic to a point where 
they'd like to support the campaign by tapping into users dreaming of a Free 
device running Plasma Mobile. One idea that floated around was a video showing 
some possibilities and ideas.

Something like this should happen together with Purism, though, as that would 
strengthen the message, prevent communication problems and make expectations 
management easier (we surely don't want to leave backers or other people 
disappointed).

Who should we talk about joint promo with within Purism?

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org
-- 
http://vizZzion.org

Re: Plasma Mobile on the Librem 5

[Zlatan Todoric]

On 08/30/2017 03:43 PM, Matthias Klumpp wrote:
> 2017-08-29 16:44 GMT+02:00 Sebastian Kügler :
> [...]
>> Would it make sense to get together and look at Plasma Mobile and
>> Purism's plans, and devise a possible strategy and next steps? Maybe
>> get together in a video conference with everybody interested in this
>> project, and see how we can work out common ground and plans, and how
>> we can kick things off?
> I would like that a lot, I think it's a good way forward.
> @Zlatan, what do you think?
> We would need to have a bit of internal discussion first though, and
> maybe need to wait for the campaign to succeed first.
>
> Cheers,
> Matthias
>
Absolutely agree, that once we have successful campaign (otherwise we
are without device and on ground zero again), we should (and in this
case we will) sit down with KDE community and discuss the effort forward
in detail as I am also internally proponent of plasma-mobile readiness
compare to current GNOME stack.

Happy hacking,
Z

Re: Plasma Mobile on the Librem 5

[Marco Martin]

On mercoledì 30 agosto 2017 15:43:17 CEST Matthias Klumpp wrote:
> I think Plasma Mobile's current feature set pretty much covers what we
> need already - the only thing needed would be system integration and
> lots of design & polish. But I guess I need to try the phone UI again,
> instead of just watching videos of it :-) (last time hands-on was last
> year at Akademy).

about the central plasma shell itself, also note that (as the desktop version) 
is very modular, so any piece can be changed/redesigned as the need arise

--
Marco Martin

Re: Plasma Mobile on the Librem 5

[Sebastian Kügler]

On woensdag 30 augustus 2017 16:04:02 CEST Matthias Klumpp wrote:
> > - Web browser: we have QtWebengine based Angelfish browser for
> > mobile
> 
> Interesting, I didn't know a dedicated browser existed. There is some
> talk about using Firefox here, but I do not know any details on it
> yet.
> In any case, having a browser that is already optimized for mobile is
> great!

A bit of a caveat here: Angelfish is more or less a demo, it has some 
shortcuts (for example SSL support is lacking, so it shouldn't be used 
seriously at this point). I've written it since I wanted to get
familiar with QtWebEngine mainly, and as demo for Plasma Mobile. It
could be taken to serious levels, but would definitely need some work.
Given the important of a decent browser, Firefox (or something else
entirely) may well be a better option.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-08-30 9:24 GMT+02:00 Bhushan Shah :
> Hello Matthias and all,
>
> First of all huge thanks for reaching to us!
>
> On Tue, Aug 29, 2017 at 03:28:36PM +0200, Matthias Klumpp wrote:
>> As some of you might already know, we at Purism are planning to
>> develop a mobile phone that uses only free software and Matrix[2] for
>> communication. We are currently running a crowdfunding campaign[1] in
>> order to be able to make the phone a reality.
>
> Best of luck for that campaign! I will reach out to KDE Promo people as
> well to help spread a word about this campaign.

That would be awesome! Thank you for considering this!

>> [...]
> I see no issues with this, in fact Plasma Mobile platform is designed
> with ability to switch underlying distribution in mind, we also have
> some experimental Arch Linux ARM based images in addition to normal
> Ubuntu ARM images. Basically following are the requirements for Plasma
> Mobile stack.
>
> - Logind/Consolekit
> - Libinput
> - Ofono, Telepathy (For calling functionalities)
> - Qt5 (5.7.1 minimum, 5.9 recommended)
> - Wayland
> - DRM/HWcomposer/Framebuffer for graphics
> - Login manager with wayland session support (SDDM for example)
>
> If any distribution provides those, it can work as a base for the Plasma
> Mobile.

That pretty much describes any modern Linux system, PureOS or even
stock Debian support this with ease.

>> The system will make full use of systemd and will use Bubblewrap[6]
>> for sandboxing of selected more critical components.
>
> This is interesting, We Plasma devevlopers haven't looked into
> Bubblewrap so far, but it would be useful from the initial glance at
> documentation it seems.

Bubblewrap is an amazing piece of software. It comes with a slight
performance penalty for startup, but gives you a well audited and
relatively easy to use sandboxing solution. Bubblewrap is used by
Flatpak to sandbox its applications, and a couple of other projects
make use of it as well.

>> Due to the nature of the hardware, we will not need libhybris or any
>> Android kernel abstraction, which means that we can run stock Linux on
>> the phone, which greatly simplifies development and will allow us to
>> develop at a faster pace, due to not being bound to a specific kernel
>> version.
>
> YAY! As Sebastian mentioned in his reply this is the dream for us and
> also lot of users.

Yes indeed :-) It's probably the thing I am most excited about myself :D

>> The downside is that the i.mx6 ARM CPU isn't incredibly fast. We hope
>> that we will be able to update to the faster i.mx8 when it is
>> available and can be used with free drivers, but at this point in time
>> we need to focus on the i.mx6 as primary hardware target.
> [...]
> Other bit I am unsure about is, mobile baseband. Tech specs on the
> campaign page mentions just "Separate mobile baseband" without any
> further details. Though assuming that mobile baseband is supported by
> ofono [2][3] Plasma Phone will work with it.

The problem here is that we need to find one which has working drivers
and open-sourced firmware, which will be a bit challenging. We haven't
settled on anything yet, that's why this item is unspecified on the
campaign page for now. In any case, whetever we come up with will need
to support OFono.

>
>> ## What we need from a phone UI
>>
>> Our scope for this project is limited, in order to be able to complete
>> it successfully and not end up in a never ending development loop: The
>> phone should be able to communicate via Matrix, have a web browser,
>> make calls, take pictures. We are not aiming for a massive amount of
>> apps, but instead want the basic functionalities of the phone working
>> well when we ship it - more apps and features can be delivered later
>> via Flatpaks and system updates.
>
> To meet the need of Librem, we have following,
>
> - A simple yet functional phone shell

Yay!

> - Web browser: we have QtWebengine based Angelfish browser for mobile

Interesting, I didn't know a dedicated browser existed. There is some
talk about using Firefox here, but I do not know any details on it
yet.
In any case, having a browser that is already optimized for mobile is great!

> - Calling: Dialer application and a simple contacts application which
>   supports vcard based storage, can be extended with KPeople[4]
>   framework. Actual calling functionality is handled through
>   telepathy-ofono[5] and telepathy-ofono-ril-mc-plugin[5] (part of same
>   sources as telepathy-ofono). However Librem 5 won't need the
>   ril-mc-plugin, given it won't be using Android based RILd.
>
> - Take Pictures: We have very simple camera application which uses Qt's
>   Camera API, however it hasn't evolved much due to various issues with
>   Android HAL itself. Though nothing that can't be improved, for viewing
>   Photos itself, we have simple Kirigami based application named
>   Koko[6].

Cool!

> - Matrix: Unfortunately we don't have any application supporting Matrix
>   

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-08-29 18:39 GMT+02:00 Martin Flöser :
> Am 2017-08-29 15:28, schrieb Matthias Klumpp:
>>
>> What we would be interested in is knowing about the future plans for
>> Plasma Mobile, especially in the area of design and performance
>> improvements. I didn't have the opportunity yet to test Plasma Mobile
>> on one of our development boards, but I hope I can get to that
>> soonish.
>
> Speaking for the KWin (Wayland compositor) part. Ideal would be drm support
> in the phone directly, but that is probably just wishful thinking.

The Vivante GPU on the i.mx6 is supported natively by the Linux
Etnaviv driver, which should make Wayland work instantly without too
many troubles (I would need to verify that though, maybe we need to do
a bit of kernel work to make the driver ready).

> KWin does
> have a working Android hwcomposer backend through libhybris. That works well
> and good for the limited use cases we had so far. The code base of this
> plugin is extremely small (< 1000 lines of code), which shows that most of
> the code is shared and it's relatively easy to extend and adjust this code
> base for new needs.
>
> Having done the initial port of KWin to the Nexus 5 I can proudly say that
> KWin performs very well on such kind of hardware. We benefit a lot from
> performance improvements done in the general KWin stack. And we can bring
> improvements from other platforms also to the phone stack. For example Roman
> did a lot of work to get layered compositing working in the DRM platform and
> that would be an ideal candidate to bring also in the hwcomposer plugin.
> Thus we have all the heavy lifting done to do things like rendering videos
> directly in a hardware plane.

Very nice :) I am fully convinced of the quality of the KWin
compositor, and I do not think we will run into troubles with it on
the Librem 5 hardware, as long as the Linux drivers work as expected
(as usual, there is a chance that we might need some fiddling to get
this to work properly).

> One of the things currently being worked on for the phone is to get rid of
> XWayland. This could give you a nice performance boost as you have a Wayland
> only system (of course it's also nice to have X support, but one cannot get
> it with GL support, so the gain is not worth it IMHO).

I am relatively sure that Zlatan (or CTO) would make pure Wayland a
pretty high priority ;-) Personally, I would not even bother with X on
the phone and just require everything running there to use Wayland. I
briefly thought that having X is useful for the convergence usecase
(if that becomes a reality), but even for that the apps need some
level of adjustment for a phone already, and in that case walking the
extra mile to get things to work with Wayland makes sense.

Cheers,
Matthias

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-08-29 16:44 GMT+02:00 Sebastian Kügler :
> Hi Matthias, et al!
>
> On Tue, 29 Aug 2017 15:28:36 +0200
> Matthias Klumpp  wrote:
>> [ Please keep the CC list intact for replies ]
>>
>> [...]
>
> Yes, Kirigami has been rather a success story, and we see more and more
> applications adopting it. That means that they will work much better
> also on mobile devices, such as phones. (It doesn't necessarily mean
> that they'll run and work entirely perfectly on a phone, but moves them
> from "this is clearly a desktop-focused UI into "small, fixable
> niggles".)

As usual with software :-)

>> ## Some details about the phone software
>>
>> The base operating system of the phone will be PureOS[3], our Debian
>> derivative that is currently pending endorsement from the FSF.
>> The plan is to use OSTree[4] for the base system, in order to achieve
>> atomic updates and easy rollbacks, as well as Flatpaks[5] for
>> deployment of applications. It is likely that we will have our own
>> Flatpak repository with apps specifically for the phone at some point
>> in the future.
>
> Great, this is a direction we've been pursuing as well, e.g. by adding
> support for Flatpak to discover, our package manager client (and KDE
> Store / OCS client). Discover uses Kirigami as well, by the way, so it
> works well on a smartphone already.

Yes, and Discover is a key component of the whole OS stack. There was
a talk by Jan at GUADEC about the state of Flatpak in KDE Discover,
and the status seemed to be "almost done". (I also tested this a while
back without problems).

>> The system will make full use of systemd and will use Bubblewrap[6]
>> for sandboxing of selected more critical components.
>
> Interesting, makes a lot of sense. I can't really comment from a Plasma
> point of view on this, it's something we need to try and if necessary,
> make work.

This is more of an OS-wide approach to isolate components better - in
the long run, I hope we can have vulnerability mitigation in place
from the kernel to the apps wherever it makes sense.

>> [...]

>> Our scope for this project is limited, in order to be able to complete
>> it successfully and not end up in a never ending development loop: The
>> phone should be able to communicate via Matrix, have a web browser,
>> make calls, take pictures. We are not aiming for a massive amount of
>> apps, but instead want the basic functionalities of the phone working
>> well when we ship it - more apps and features  can be delivered later
>> via Flatpaks and system updates.
>>
>> The UI therefore doesn't need to be excessive and support each and
>> every feature that Android already has, having a more minimal UI works
>> fine.
>
> I think that's a very valid approach. Catching up with Android (or iOS)
> in a short time-frame won't work, and it's better and more realistic to
> concentrate on a limited feature set and extend from there.
>
> That said, we have a reasonably working shell / workspace UI to launch
> and switch between apps, and a bunch of essential system controls, so
> we should offer a state which isn't too far from a basic usable system
> (except perhaps for Matrix support, but I'd suggest to read Eike's
> email, he's our chat goto guy and knows these ins and outs much better
> than I do).
>
> I think it would make sense to sit down and look at the delta between
> what you have in mind as a basic feature set and what we currently
> have, and then evaluate what we need to work on and prioritize based on
> that.

I think Plasma Mobile's current feature set pretty much covers what we
need already - the only thing needed would be system integration and
lots of design & polish. But I guess I need to try the phone UI again,
instead of just watching videos of it :-) (last time hands-on was last
year at Akademy).

> [...]
> We've been continuously improving our memory requirements (actually
> across the whole stack including Plasma desktop), and we will continue
> to do that. Bugfixing is of course among our top priorities.
>
> Aside from the obvious, embedded targets (not just phones, but also
> mini computers such as ODROID C1+, Pine64, Pinebook are an increasingly
> important target for us, so there's more performance work going to come
> in that specific area as well.
>
> What we're currently lacking is enthusiasm from people who want to work
> at the user interface level. We're running into a bit of a
> chicken-and-egg problem here, as we've long lacked viable target
> devices for Plasma Mobile, and a platform that only runs on very
> specific hardware and isn't at end-user quality (or very, very close)
> is not that attractive to many people.

This was pretty much the result of our "Debian Mobile" BoF that we had
at this year's Debconf as well - it's a tricky to solve problem, but
the Librem 5 could help a bit with that.

> [...]
> I think a project such as the librem could attract a lot of interest
> from the community, but we need to do a 

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-08-29 15:58 GMT+02:00 Eike Hein :
>
> On 08/29/2017 10:28 PM, Matthias Klumpp wrote:
>> As some of you might already know, we at Purism are planning to
>> develop a mobile phone that uses only free software and Matrix[2] for
>> communication. We are currently running a crowdfunding campaign[1] in
>> order to be able to make the phone a reality.>
>> [...]
>>
>> Our scope for this project is limited, in order to be able to complete
>> it successfully and not end up in a never ending development loop: The
>> phone should be able to communicate via Matrix, have a web browser,
>> make calls, take pictures. We are not aiming for a massive amount of
>> apps, but instead want the basic functionalities of the phone working
>> well when we ship it - more apps and features can be delivered later
>> via Flatpaks and system updates.
>
> Very interesting!
>
> I'll let others reply about some of the more Plasma Mobile-specific
> parts as they're better equipped to do so and will focus on the Matrix
> part, as it piqued my interest with my "Konversation developer" hat on.
>
> Konversation is KDE's IRC client. As a by-product of an (ongoing)
> conversation within the KDE community on whether we want to stick by IRC
> or move on to another chat solution as 'the one' for the community, and
> how to transition smoothly, we're currently (a) rewriting the UI to be
> more convergent and allow for a mobile version and (b) looking to
> retarget it as an IRC/Matrix client.
>
> This is a very early effort currently focused on UI experimentation and
> rampup (read: there are no Matrix bits yet, although the Konvi team has
> been following Matrix for a while and is to a degree familiar with the
> technology). After a few initial sessions of hacking this months, here
> are some (working and chatting) mockups of the UI direction:
>
> https://www.youtube.com/watch?v=1cr7hirDzws=1
> https://www.youtube.com/watch?v=b88oqdlNyuU=1
> http://imgur.com/a/bT7XE
>
> As you can see the UI is headed toward a responsive/convergent bent
> (here with desktop-specific concessions) using KDE's Kirigami UI technology.
>
> As one of the main problems the community has with IRC is the poor state
> of mobile access, a mobile version of Konversation for both Plasma
> Mobile and Android - both platforms Kirigami easily deploys to - is
> definitely planned, leveraging both Kirigami's convergent nature (and
> meaning it, not buzzword bingo) and the ability to do form
> factor-specific customization via KPackage. This work is currently being
> done in collab with KDE's Visual Design group and with (code, advice)
> support from the Kirigami team as well.
>
> Again, it's the early days of this effort - but I can confirm Matrix is
> something we're interested in and gearing up to hack on, motivated in
> large part by mobile. We share that one.

I was made aware of that effort already a few weeks ago, and it is
looking great! I guess the default Matrix app in the Librem phone
would have to be something focused on person-to-person communication
and tight integration with the user's contact list, instead of being
more group-chat centric like Konversation is. But having more choice
in Matrix clients is a good thing, and maybe we can have different UIs
for the same backend.
Keep up the good work!

Re: Plasma Mobile on the Librem 5

[Bhushan Shah]

Hello Matthias and all,

First of all huge thanks for reaching to us!

On Tue, Aug 29, 2017 at 03:28:36PM +0200, Matthias Klumpp wrote:
> As some of you might already know, we at Purism are planning to
> develop a mobile phone that uses only free software and Matrix[2] for
> communication. We are currently running a crowdfunding campaign[1] in
> order to be able to make the phone a reality.

Best of luck for that campaign! I will reach out to KDE Promo people as
well to help spread a word about this campaign.

> One of the open questions for the phone is still which UX we will use,
> and Plasma Mobile would obviously be a perfect fit for this kind of
> project, since KDE and Purism share the same values, the UI is already
> done in large parts, and nothing would have to be developed from
> scratch (especially the Kirigami controls are great!).

Yep, and in addition, Kirigami also supports the 'Convergence' usecase
listed in Librem 5 campaign. You will be able to re-use same
applications on big monitor and small screen.

See also: https://community.kde.org/Plasma/Convergence_Overview

> ## Some details about the phone software
> 
> The base operating system of the phone will be PureOS[3], our Debian
> derivative that is currently pending endorsement from the FSF.
> The plan is to use OSTree[4] for the base system, in order to achieve
> atomic updates and easy rollbacks, as well as Flatpaks[5] for
> deployment of applications. It is likely that we will have our own
> Flatpak repository with apps specifically for the phone at some point
> in the future.

I see no issues with this, in fact Plasma Mobile platform is designed
with ability to switch underlying distribution in mind, we also have
some experimental Arch Linux ARM based images in addition to normal
Ubuntu ARM images. Basically following are the requirements for Plasma
Mobile stack.

- Logind/Consolekit
- Libinput
- Ofono, Telepathy (For calling functionalities)
- Qt5 (5.7.1 minimum, 5.9 recommended)
- Wayland
- DRM/HWcomposer/Framebuffer for graphics
- Login manager with wayland session support (SDDM for example)

If any distribution provides those, it can work as a base for the Plasma
Mobile.

> The system will make full use of systemd and will use Bubblewrap[6]
> for sandboxing of selected more critical components.

This is interesting, We Plasma devevlopers haven't looked into
Bubblewrap so far, but it would be useful from the initial glance at
documentation it seems.

> Due to the nature of the hardware, we will not need libhybris or any
> Android kernel abstraction, which means that we can run stock Linux on
> the phone, which greatly simplifies development and will allow us to
> develop at a faster pace, due to not being bound to a specific kernel
> version.

YAY! As Sebastian mentioned in his reply this is the dream for us and
also lot of users.

> The downside is that the i.mx6 ARM CPU isn't incredibly fast. We hope
> that we will be able to update to the faster i.mx8 when it is
> available and can be used with free drivers, but at this point in time
> we need to focus on the i.mx6 as primary hardware target.

I want to mention some hardware enablement bits I've in mind, from what
I know i.mx6 have Vivante GPU, and Etnaviv already seems to support the
Direct Rendering Manager and Wayland [1], so it should be easy enough to
support the KWin/Wayland with DRM backend.

Other bit I am unsure about is, mobile baseband. Tech specs on the
campaign page mentions just "Separate mobile baseband" without any
further details. Though assuming that mobile baseband is supported by
ofono [2][3] Plasma Phone will work with it.

> ## What we need from a phone UI
> 
> Our scope for this project is limited, in order to be able to complete
> it successfully and not end up in a never ending development loop: The
> phone should be able to communicate via Matrix, have a web browser,
> make calls, take pictures. We are not aiming for a massive amount of
> apps, but instead want the basic functionalities of the phone working
> well when we ship it - more apps and features can be delivered later
> via Flatpaks and system updates.

To meet the need of Librem, we have following,

- A simple yet functional phone shell

- Web browser: we have QtWebengine based Angelfish browser for mobile

- Calling: Dialer application and a simple contacts application which
  supports vcard based storage, can be extended with KPeople[4]
  framework. Actual calling functionality is handled through
  telepathy-ofono[5] and telepathy-ofono-ril-mc-plugin[5] (part of same
  sources as telepathy-ofono). However Librem 5 won't need the
  ril-mc-plugin, given it won't be using Android based RILd.

- Take Pictures: We have very simple camera application which uses Qt's
  Camera API, however it hasn't evolved much due to various issues with
  Android HAL itself. Though nothing that can't be improved, for viewing
  Photos itself, we have simple Kirigami based application named
  Koko[6].

- Matrix: 

Re: Plasma Mobile on the Librem 5

[Martin Flöser]

Am 2017-08-29 15:28, schrieb Matthias Klumpp:

What we would be interested in is knowing about the future plans for
Plasma Mobile, especially in the area of design and performance
improvements. I didn't have the opportunity yet to test Plasma Mobile
on one of our development boards, but I hope I can get to that
soonish.


Speaking for the KWin (Wayland compositor) part. Ideal would be drm 
support in the phone directly, but that is probably just wishful 
thinking. KWin does have a working Android hwcomposer backend through 
libhybris. That works well and good for the limited use cases we had so 
far. The code base of this plugin is extremely small (< 1000 lines of 
code), which shows that most of the code is shared and it's relatively 
easy to extend and adjust this code base for new needs.


Having done the initial port of KWin to the Nexus 5 I can proudly say 
that KWin performs very well on such kind of hardware. We benefit a lot 
from performance improvements done in the general KWin stack. And we can 
bring improvements from other platforms also to the phone stack. For 
example Roman did a lot of work to get layered compositing working in 
the DRM platform and that would be an ideal candidate to bring also in 
the hwcomposer plugin. Thus we have all the heavy lifting done to do 
things like rendering videos directly in a hardware plane.


One of the things currently being worked on for the phone is to get rid 
of XWayland. This could give you a nice performance boost as you have a 
Wayland only system (of course it's also nice to have X support, but one 
cannot get it with GL support, so the gain is not worth it IMHO).


Cheers
Martin

Re: Plasma Mobile on the Librem 5

[Sebastian Kügler]

Hi Matthias, et al!

On Tue, 29 Aug 2017 15:28:36 +0200
Matthias Klumpp  wrote:
> [ Please keep the CC list intact for replies ]
> 
> Hi!
>
> As some of you might already know, we at Purism are planning to
> develop a mobile phone that uses only free software and Matrix[2] for
> communication. We are currently running a crowdfunding campaign[1] in
> order to be able to make the phone a reality.
> 
> One of the open questions for the phone is still which UX we will use,
> and Plasma Mobile would obviously be a perfect fit for this kind of
> project, since KDE and Purism share the same values, the UI is already
> done in large parts, and nothing would have to be developed from
> scratch (especially the Kirigami controls are great!).

Yes, Kirigami has been rather a success story, and we see more and more
applications adopting it. That means that they will work much better
also on mobile devices, such as phones. (It doesn't necessarily mean
that they'll run and work entirely perfectly on a phone, but moves them
from "this is clearly a desktop-focused UI into "small, fixable
niggles".)

> ## Some details about the phone software
> 
> The base operating system of the phone will be PureOS[3], our Debian
> derivative that is currently pending endorsement from the FSF.
> The plan is to use OSTree[4] for the base system, in order to achieve
> atomic updates and easy rollbacks, as well as Flatpaks[5] for
> deployment of applications. It is likely that we will have our own
> Flatpak repository with apps specifically for the phone at some point
> in the future.

Great, this is a direction we've been pursuing as well, e.g. by adding
support for Flatpak to discover, our package manager client (and KDE
Store / OCS client). Discover uses Kirigami as well, by the way, so it
works well on a smartphone already.

> The system will make full use of systemd and will use Bubblewrap[6]
> for sandboxing of selected more critical components.

Interesting, makes a lot of sense. I can't really comment from a Plasma
point of view on this, it's something we need to try and if necessary,
make work.

> Due to the nature of the hardware, we will not need libhybris or any
> Android kernel abstraction, which means that we can run stock Linux on
> the phone, which greatly simplifies development and will allow us to
> develop at a faster pace, due to not being bound to a specific kernel
> version.

That. Is. Awesome. (One of our wet dreams, actually!)

> The downside is that the i.mx6 ARM CPU isn't incredibly fast. We hope
> that we will be able to update to the faster i.mx8 when it is
> available and can be used with free drivers, but at this point in time
> we need to focus on the i.mx6 as primary hardware target.

It would be good to be able to try Plasma Mobile on a development
board and identify performance bottlenecks, then we can evaluate what
it needs to fix these to make it all run fast enough. I don't think we
can sensibly say "well, this hardware is fast enough / too slow" before
we actually try it. In the end, it's software, so we should be able to
make it run acceptably fast.

> ## What we need from a phone UI
> 
> Our scope for this project is limited, in order to be able to complete
> it successfully and not end up in a never ending development loop: The
> phone should be able to communicate via Matrix, have a web browser,
> make calls, take pictures. We are not aiming for a massive amount of
> apps, but instead want the basic functionalities of the phone working
> well when we ship it - more apps and features  can be delivered later
> via Flatpaks and system updates.
> 
> The UI therefore doesn't need to be excessive and support each and
> every feature that Android already has, having a more minimal UI works
> fine.

I think that's a very valid approach. Catching up with Android (or iOS)
in a short time-frame won't work, and it's better and more realistic to
concentrate on a limited feature set and extend from there.

That said, we have a reasonably working shell / workspace UI to launch
and switch between apps, and a bunch of essential system controls, so
we should offer a state which isn't too far from a basic usable system
(except perhaps for Matrix support, but I'd suggest to read Eike's
email, he's our chat goto guy and knows these ins and outs much better
than I do).

I think it would make sense to sit down and look at the delta between
what you have in mind as a basic feature set and what we currently
have, and then evaluate what we need to work on and prioritize based on
that.

> ## Purism and KDE
> 
> While Purism is using GNOME for its laptops by default for various
> reasons, partnering with KDE for the phone does make a lot of sense
> for us, and we are excited about it. There are a few ways we can think
> of how to help the Plasma Mobile team, and this email is intended to
> make first contact and allow you to ask us any questions.
> 
> What we would be interested in is knowing about the 

Re: Plasma Mobile on the Librem 5

[Eike Hein]

On 08/29/2017 10:28 PM, Matthias Klumpp wrote:
> As some of you might already know, we at Purism are planning to
> develop a mobile phone that uses only free software and Matrix[2] for
> communication. We are currently running a crowdfunding campaign[1] in
> order to be able to make the phone a reality.>
> [...]
>
> Our scope for this project is limited, in order to be able to complete
> it successfully and not end up in a never ending development loop: The
> phone should be able to communicate via Matrix, have a web browser,
> make calls, take pictures. We are not aiming for a massive amount of
> apps, but instead want the basic functionalities of the phone working
> well when we ship it - more apps and features can be delivered later
> via Flatpaks and system updates.

Very interesting!

I'll let others reply about some of the more Plasma Mobile-specific
parts as they're better equipped to do so and will focus on the Matrix
part, as it piqued my interest with my "Konversation developer" hat on.

Konversation is KDE's IRC client. As a by-product of an (ongoing)
conversation within the KDE community on whether we want to stick by IRC
or move on to another chat solution as 'the one' for the community, and
how to transition smoothly, we're currently (a) rewriting the UI to be
more convergent and allow for a mobile version and (b) looking to
retarget it as an IRC/Matrix client.

This is a very early effort currently focused on UI experimentation and
rampup (read: there are no Matrix bits yet, although the Konvi team has
been following Matrix for a while and is to a degree familiar with the
technology). After a few initial sessions of hacking this months, here
are some (working and chatting) mockups of the UI direction:

https://www.youtube.com/watch?v=1cr7hirDzws=1
https://www.youtube.com/watch?v=b88oqdlNyuU=1
http://imgur.com/a/bT7XE

As you can see the UI is headed toward a responsive/convergent bent
(here with desktop-specific concessions) using KDE's Kirigami UI technology.

As one of the main problems the community has with IRC is the poor state
of mobile access, a mobile version of Konversation for both Plasma
Mobile and Android - both platforms Kirigami easily deploys to - is
definitely planned, leveraging both Kirigami's convergent nature (and
meaning it, not buzzword bingo) and the ability to do form
factor-specific customization via KPackage. This work is currently being
done in collab with KDE's Visual Design group and with (code, advice)
support from the Kirigami team as well.

Again, it's the early days of this effort - but I can confirm Matrix is
something we're interested in and gearing up to hack on, motivated in
large part by mobile. We share that one.


Cheers,
Eike