Much better and thanks! LGTM

Add another code example showing now you could use it as a loading indicator

Urgh, I knew there was a point to that damn fwidth() call. As far as I can tell this version has about the same visual appearance without it changing dependent on resolution.

• Restore fwidth() call in shader, tweak smoothing values more

• Remove sdf_polygon, it is unused and causes breakage on Android

Actually, width does affect the roughness. The corners are at their smoothest when the card is a square.

I found something very curious and I don't know what the cause could be. The corners are smoother when the cards are taller and rougher when they are shorter. Width doesn't affect smoothness.

• Slightly increase smoothing, to avoid too harsh corners

Nice! Got a few places where this could be very handy :)

so, let's try to vertically center when the size is less than the parent

Add margins to examples

Close. There's extra spacing on the right for some reason, and I think the sidebar's background used to be white.

Switch between ListView and CardsLayout

That was fixed, thanks.

This appears to have broken SwipeListItem. Now the actions don't show up anymore and there's loads of console spam:

file:///home/nate/kde/usr/lib64/qml/org/kde/kirigami.2/templates/SwipeListItem.qml:421: TypeError: Type error
file:///home/nate/kde/usr/lib64/qml/org/kde/kirigami.2/templates/SwipeListItem.qml:421: TypeError: Type error
file:///home/nate/kde/usr/lib64/qml/org/kde/kirigami.2/templates/SwipeListItem.qml:421: TypeError: Type error

This seems to be causing regressions to card behaviour for me.

Adjust tab stylings

All right, you've convinced me.

Look cool!

Address review comments

In D28873#652724, @mart wrote:

for those that are a sidebar, there is already a standard, agreed upon look, that is being slowly and painfully moved to be adopted, which is:

• Rebase on most recent master
• Use ShadowedRectangleNode for ShadowedTexture if source is not set
• Use transparent color for BannerImage's ShadowedImage
• Hide BannerImage scrim if source or title is not set
• Don't set ShadowedTexture source if Image is not properly loaded
• Add tintWithAlpha method to ColorUtils
• Use new tintWithAlpha for border colors

In D28873#653148, @cblack wrote:

IMO, the affordances of a traditional tab style hint at tabs being editable. This is fairly established: Chrome uses the traditional tab style for its user-manipulatable tabs, while using a different style for non-manipulatable tabs. Firefox does the same, as well as Falkon. elementary on a platform level uses traditional tabs for manipulatable tabs and a different style for static tabs. macOS does the same thing. Using editable-style tabs when the tabs are non-editable is a misleading affordance, hence why this patch doesn't use them.

In D28873#652727, @ngraham wrote:

"Lateral navigation" is basically a tabbed view. So to me this looks like a tabbed view with a different UI for the tabs. We've actually needed a tabbed view component for a while: https://bugs.kde.org/show_bug.cgi?id=394296

Maybe this could be that. I think the swipe navigation is fine. However if this is going to have all the functionality of a tabbed view, it ought to look like a desktop-style tabbed view on the desktop platform. The different tab styling therefore has to go. On mobile, the tabs should look like desktop tabs, and on mobile, the tabs should look like mobile tabs.

Nice job! I was actually just about to submit this exact diff. :)

btw may be worth trying to have a stackview that switches between this view and the one before based on page with (wideMode property of pagerow)

if there can't be a super smooth transition between a listview and this thing (perhaps with a stackview, but i'm not sold) then there should always be just the cardlayout with the same cards look, just as a single column

In D28873#652747, @ngraham wrote:

Like you mentioned, don't we want to use the tabbed sidebar view thingy for that?

Like you mentioned, don't we want to use the tabbed sidebar view thingy for that?

This patch is about having the whole app navigation as a tabbed thing, so more like tabs in a webbrowser than a generic tabview (with frame and all which this shouldn't have)
so they are 2 different things: i still think a drop in replacement for a tabview will be needed, but this is probably different beast

In D28971#652708, @mart wrote:

my concern here using qsettings in this place, is that then it kinda clashes when an application uses its own config like it should, from a framework (kconfiggroup, kconfigskeleton etc)
i always refrained from using any form of config read/write here, and i think we should continue to do so.
Kirigami is a tier1 framework that should do the kleast possible, is more like KGuiAddons/§KWidgetAddons, *not* a full feature kxmlgui, which if we want to have something along the lines, we should have a proper framework to do so, and not tier1

ok, thanks for the clarification

what's the "tools area"?
are there other use cases than client side decorations? (which we don't want to support)

"Lateral navigation" is basically a tabbed view. So to me this looks like a tabbed view with a different UI for the tabs. We've actually needed a tabbed view component for a while: https://bugs.kde.org/show_bug.cgi?id=394296

In D28873#649459, @niccolove wrote:

My opinion from the consistency side: I actually think this is a good possibility for the Consistency goal. After some digging around, my opinion is that

Tabs should only be used on application views that are user-editable (eg: when it's possible to open a new tab or close another).

It's imo appropriate to have a different component for changing views, especially on Kiri. But of course, that component should be consistent. Right now we have big square sidebars, toolbars, etc etc etc etc etc

In D28971#652708, @mart wrote:

i always refrained from using any form of config read/write here, and i think we should continue to do so.

Are you referring to the gallery (this patch) or to Kirigami?

my concern here using qsettings in this place, is that then it kinda clashes when an application uses its own config like it should, from a framework (kconfiggroup, kconfigskeleton etc)
i always refrained from using any form of config read/write here, and i think we should continue to do so.
Kirigami is a tier1 framework that should do the kleast possible, is more like KGuiAddons/§KWidgetAddons, *not* a full feature kxmlgui, which if we want to have something along the lines, we should have a proper framework to do so, and not tier1

In D28625#652529, @mart wrote:

In D28625#642954, @cblack wrote:

Looks like a nice visual improvement.

Are the changes to the scenegraph stuff related? They don't look like a related change to making the Kirigami.Card use the ShadowedRectangle to me.

they should be, as far i know, a fix for the 1 pixel border that had some blurriness.
@ahiemstra can you confirm?

In D28625#642954, @cblack wrote:

Looks like a nice visual improvement.

Are the changes to the scenegraph stuff related? They don't look like a related change to making the Kirigami.Card use the ShadowedRectangle to me.

as long as you can still single click on the arrows to increment/decrement or scroll with the mouse wheel to increment/decrement, adding the ability to click/tap and drag to change the value seems like a good idea.

Window geometry and position is supposed to be saved automatically by KXMLGui, at least for widgets apps. If that's not possible to do here, perhaps we should have Kirigami do this at the frameworks level so it doesn't need to be done by every single app.

The unittest in this commit appears to break in CI.

LGTM.

the problem is as usual: easy to do with qml stuff, hacky and pain for qwidgets..
that said, the most user friendly spinbox i ever found was in a super ancient version of Corel Draw (something that still ran on windows 3.1 iirc :p)
the look was stil pretty much the same of the current spinbox, but with something that reminded an handle fused with the arrow buttons.
if one keeped the mouse pressed and dragged up and down, could make the values go up and down in a very fast, efficient and suprisingly super precise way.

In D28888#649712, @cblack wrote:

In D28888#649710, @ngraham wrote:

Hmm, now the cards collapse into weird pseudo-list-items in the sidebar. Could they just go back to using real list items instead?

That's what I initially attempted, but non-deterministic behaviour was caused by swapping out a list of cards for a list of listitems.

I can understand that there are technical challenges, but, not to put too fine a point on it, this doesn't look very good:

In D28888#649710, @ngraham wrote:

Hmm, now the cards collapse into weird pseudo-list-items in the sidebar. Could they just go back to using real list items instead?

Hmm, now the cards collapse into weird pseudo-list-items in the sidebar. Could they just go back to using real list items instead?

Use more descriptive name

Address some feedback

In D28873#649570, @camiloh wrote:

What about having as a view a component that is not a Kirigami.Page? Such as a StackView or a Rectangle. Why not use an attached property to define its title, icon and other props instead of focing to wrap those components into a kirigami.Page?

Fix faulty navigateToRoute

What about having as a view a component that is not a Kirigami.Page? Such as a StackView or a Rectangle. Why not use an attached property to define its title, icon and other props instead of focing to wrap those components into a kirigami.Page?

My opinion from the consistency side: I actually think this is a good possibility for the Consistency goal. After some digging around, my opinion is that

The tabbars have their own look, which it's against the consistency goal. I do prefer this look to the current breeze one, but this is a debate to have at the level of the future breeze direction.
It's ok in the case of mobile with the tbbar on the bottom as it's a pretty standard mobile control with an established look and feel, but a top tabbar on the desktop should look like any other tabbar

So are these all views that run simultaneously like apps on a task bar? What makes this different from tabs?

In D28873#649388, @ndavis wrote:

What is the usecase for this?

Apps that have shallow and primarily lateral navigation.

What is the usecase for this?