WRT the gravatar bit, I'm not married to it, it's just a way to have this moving forward.

I'll add some screenshots so you get an idea:

That's a great idea! Would it be possible:

• to also (optionally) support the translators' information, like in the current about box? (probably in a future patch, but maybe some groundwork is needed here)
• to move this about page to some common kirigami-addons library?

In D17079#363906, @ltoscano wrote:

That's a great idea! Would it be possible:

• to also (optionally) support the translators' information, like in the current about box? (probably in a future patch, but maybe some groundwork is needed here)

Yes, I actually forgot to add it, it's basically a matter of replicating the authors bit but instead of calling .authors, we call .translators. Actually we should do the same for contributors too.

• to move this about page to some common kirigami-addons library?

We would have to look into it, we don't want to have kirigami depend on kcoreaddons, but we can easily allow applications that don't use kcoreaddons to pass a json object that looks like KAboutData instance (duck typing!).
Otherwise, we could also move it to kdeclarative or have kcoreaddons install it.

Cool!

For this design, I'd like to get rid of the tabs and put everything in a scrollview. We generally have enough space that a tabbed view is overkill.

Basically what Nate said, this is a great idea :) Thinking that having this is already an improvement, but also perhaps that having it as a scrollable page would indeed feel more natural here rather than tabs... Thinking this seems like a good place to use the fact that Cards are good for not-quite-similar data, or am i off there?

In D17079#363975, @ngraham wrote:

Cool!

For this design, I'd like to get rid of the tabs and put everything in a scrollview. We generally have enough space that a tabbed view is overkill.

+1

I think this ui should really go into KCoreAddons itself. Would it be accepted there?

In D17079#364157, @mart wrote:

I think this ui should really go into KCoreAddons itself. Would it be accepted there?

kcoreaddons is tier1 just like kirigami. Why not create a new Frameworks, kirigami-addons (or another appropriate name), which would collect all the common UI items which depends on other frameworks? Basically the kxmlgui of Kirigami.

In D17079#364163, @ltoscano wrote:

In D17079#364157, @mart wrote:

I think this ui should really go into KCoreAddons itself. Would it be accepted there?

kcoreaddons is tier1 just like kirigami. Why not create a new Frameworks, kirigami-addons (or another appropriate name), which would collect all the common UI items which depends on other frameworks? Basically the kxmlgui of Kirigami.

I think an external framework is a big overkill. In this case, it's only runtime dependencies so both either kcoreaddons or kirigami could offer it. I would favor putting it in kirigami because there's the duck-typing opportunity there too, but it may be a stretch.
That said, we'll need someone to register the KAbout* types somewhere too, but we can also rely on applications doing that as a first iteration.

In D17079#364263, @apol wrote:

In D17079#364163, @ltoscano wrote:

In D17079#364157, @mart wrote:

I think this ui should really go into KCoreAddons itself. Would it be accepted there?

kcoreaddons is tier1 just like kirigami. Why not create a new Frameworks, kirigami-addons (or another appropriate name), which would collect all the common UI items which depends on other frameworks? Basically the kxmlgui of Kirigami.

I think an external framework is a big overkill. In this case, it's only runtime dependencies so both either kcoreaddons or kirigami could offer it. I would favor putting it in kirigami because there's the duck-typing opportunity there too, but it may be a stretch.
That said, we'll need someone to register the KAbout* types somewhere too, but we can also rely on applications doing that as a first iteration.

one thing i'm a bit concerned is kirigami becomeing too much of a QML kdelibs monolith :p

In D17079#364308, @mart wrote:

In D17079#364263, @apol wrote:

In D17079#364163, @ltoscano wrote:

kcoreaddons is tier1 just like kirigami. Why not create a new Frameworks, kirigami-addons (or another appropriate name), which would collect all the common UI items which depends on other frameworks? Basically the kxmlgui of Kirigami.

I think an external framework is a big overkill. In this case, it's only runtime dependencies so both either kcoreaddons or kirigami could offer it. I would favor putting it in kirigami because there's the duck-typing opportunity there too, but it may be a stretch.
That said, we'll need someone to register the KAbout* types somewhere too, but we can also rely on applications doing that as a first iteration.

one thing i'm a bit concerned is kirigami becomeing too much of a QML kdelibs monolith :p

This came up when discussing date/time input widgets at Akademy as well. The idea there was also to have tier2 framework ("kirigami-addons") for this kind of stuff. Ie. higher-level controls that depend on Kirigami and possibly other tier1 frameworks, but unlike kdeclarative doesn't pull in QtWidgets as a dependency. So this wouldn't be just for the about page, but seems of much broader use.