Provide a qqc2/kirigami-based about page
ClosedPublic

Authored by apol on Nov 21 2018, 6:07 PM.

Details

Summary

Instead of using the one in xmlgui, create one that integrates properly in Kirigami/Discover.

Depends on D17078 and D17080.

Test Plan

Used it, saw myself in it.

Diff Detail

Repository
R134 Discover Software Store
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 5222
Build 5240: arc lint + arc unit
apol created this revision.Nov 21 2018, 6:07 PM
Restricted Application added a project: Plasma. · View Herald TranscriptNov 21 2018, 6:07 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
apol requested review of this revision.Nov 21 2018, 6:07 PM
apol updated this revision to Diff 45968.Nov 21 2018, 6:28 PM

Don't show the gravatar logo when not there

apol added a comment.Nov 21 2018, 6:37 PM

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?
apol added a comment.Nov 22 2018, 12:39 AM

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.

leinir added a subscriber: leinir.Nov 22 2018, 12:56 PM

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?

mart added a subscriber: mart.Nov 22 2018, 12:57 PM

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

mart added a comment.Nov 22 2018, 1:13 PM

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

mart added inline comments.Nov 22 2018, 1:20 PM
discover/qml/DiscoverWindow.qml
76

can you try how does it look for this page to be pushed as a layer instead of the main PageRow?
would be like applicationWindow().pageStack.layers.push(thecomponentorurl)
it would end up more "modal"than using the main row.
I have no idea what would be better usability-wise, but is a thing could be tried (and then codified in the hig)

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.

apol added a comment.Nov 22 2018, 3:42 PM
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.

mart added a comment.Nov 22 2018, 4:58 PM
In D17079#364263, @apol 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:

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.

This revision was not accepted when it landed; it landed in state Needs Review.Nov 26 2018, 4:57 PM
This revision was automatically updated to reflect the committed changes.