Done: https://nextcloud.com/blog/the-new-standard-in-on-premises-team-collaboration-nextcloud-hub/ :)

Definitely. This task just predates the work in D24443.

Ah ok, all good then :) Thanks!

Thanks for investigating this!

Thanks, that works for me. +1 on this then.

In D26569#592135, @apol wrote:

See https://phabricator.kde.org/D26570, we definitely want translations. Should we use the description instead?

In D26057#592147, @dfaure wrote:

Please port kdeclarative.

kdeclarative/private/kiconprovider.cpp:44:56: error: ‘IconSize’ was not declared in this scope

pixmap = QIcon::fromTheme(source.at(0)).pixmap(IconSize(KIconLoader::Desktop));

Detected by http://www.davidfaure.fr/2020/542.diff (to be applied to kdeclarative)

Thanks.

Thanks! Maybe "KDE" -> "us", to keep the vendor-neutral wording, as this is also used outside of KDE. I'm ok with the rest of the wording changes.

I'm fine with the interface, but I'm unsure whether this is human or machine read? For human consumption we might want translated texts?

In D26563#591734, @apol wrote:

+1
This makes sense, it's possibly what happened. I'm not sure how I made it happen though.

So it failed this bad because I added a wrong column?

With the infinite recursion fixed this seems to produce correct results, but the search performance in the size view is now massively worse.

As there seems to be little documentation about those changes, the following Qt git revisions are relevant:

• c8b07f7da3ff55f92378a1e98522f318bbc43077 (qtbase)
• 5bb178c479a247720fbc3fbb7f06a32b725193ac (qtbase)
• 670fdcc3f23493bc039a2676ce69892cc152dc6b (qtdeclarative)

In D26551#591356, @ngraham wrote:

Yeah, the idea behind this change was that the parent UI presenting these strings would include the explanation.

Does the standalone dialog live in this repo?

I think the stand-alone app case (as seen in the second video) now misses the motivational explanation for why we do this, in the Plasma KCM this is added independently. Maybe just add that sentence to the top of the default config dialog?

In D26532#590609, @nicolasfella wrote:

In D26532#590598, @vkrause wrote:

We are already not building a few things here on Android (including public API on other platforms), so excluding more is fine IMHO, especially if it's stuff where you can't argue an empty stub is a useful porting aid.

IIRC the case with KSNI on Android was a bit different since it never was part of the ABI on Android, whereas KPassivePopup is.

We are already not building a few things here on Android (including public API on other platforms), so excluding more is fine IMHO, especially if it's stuff where you can't argue an empty stub is a useful porting aid.

In D26428#589235, @dfaure wrote:

There is one major drawback with this plan though. There were talks about deprecating kio_http for security reasons... Adding Volker as reviewer.

Nice! I missed the about page got ported meanwhile :)

In D26074#587793, @cfeck wrote:

The stable branch "release/19.12" for kwalletmanager fails to build. Does this need to be backported for the coming 19.12.1 release?

I have a theory where this might come from, but I can't verify this here (problem is not reproduceable): KeyListModelInterface is in a different lib and is not exported (all inline), but has a vtable and RTTI data. This results in the RTTI data being duplicated in every lib/executable (as there is no exported one that can be shared), which means there's two different RTTI instances for the kleo binary and libkleo, dynamic_cast picks the wrong one in your setup, and fails. The second level cast to KeyRearrangeColumnsProxyModel (in libkleo, but exported) makes it cast from a type in the same lib, which then apparently makes it pick the right RTTI instance and succeed.

Isn't this exactly the platform abstraction vs. platform implementation conflict? Ie. can (or should) Purpose cover both sides of this? If not, we probably want something separate doing the platform abstraction, with Purpose providing the implementation on the Plasma platform (and others not having their own implementation, probably).