D28873: Add SwipeNavigator component

[Carson Black]

cblack abandoned this revision.
cblack added a comment.


  Moving to a GitLab MR

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: EspiDev, squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, 
plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, 
davidedmundson

D28873: Add SwipeNavigator component

[Carson Black]

cblack added a comment.


  In D28873#672598 , @mart wrote:
  
  > what should happen in this case?
  >  F8331924: Screenshot_20200518_114607.png 

  
  
  My answer would be "set a minimum window size", though on mobile that 
probably wouldn't be applicable.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: EspiDev, squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, 
plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, 
davidedmundson

D28873: Add SwipeNavigator component

[Marco Martin]

mart added a comment.


  what should happen in this case?
  F8331924: Screenshot_20200518_114607.png 


REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: EspiDev, squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, 
plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, 
davidedmundson

D28873: Add SwipeNavigator component

[Marco Martin]

mart added a comment.


  can you add an example about it in /examples ?

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: EspiDev, squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, 
plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, 
davidedmundson

D28873: Add SwipeNavigator component

[Nathaniel Graham]

ngraham added a comment.


  Looking fine.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: EspiDev, squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, 
plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, 
davidedmundson

D28873: Add SwipeNavigator component

[Carson Black]

cblack updated this revision to Diff 82965.
cblack added a comment.


  Improve the small toolbar

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28873?vs=82962=82965

BRANCH
  cblack/lateral (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D28873

AFFECTED FILES
  src/controls/Page.qml
  src/controls/SwipeNavigator.qml
  src/controls/private/SwipeTabBar.qml
  src/kirigamiplugin.cpp

To: cblack, #kirigami, #vdg
Cc: EspiDev, squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, 
plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, 
davidedmundson

D28873: Add SwipeNavigator component

[Carson Black]

cblack updated this revision to Diff 82962.
cblack added a comment.


  Rebase on master

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28873?vs=80804=82962

BRANCH
  cblack/lateral (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D28873

AFFECTED FILES
  src/controls/Page.qml
  src/controls/SwipeNavigator.qml
  src/controls/private/SwipeTabBar.qml
  src/kirigamiplugin.cpp

To: cblack, #kirigami, #vdg
Cc: EspiDev, squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, 
plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, 
davidedmundson

D28873: Add SwipeNavigator component

[Marco Martin]

mart added a comment.


  yes, that screenshot is really broken.
  to me is important that the tabbar tries to take all the space available 
before doing any eliding.
  Probably whether starting to elide a lot and make the tabs actually 
scrollable, will depend case by case depending fro mthe app

INLINE COMMENTS

> SwipeNavigator.qml:83
> +
> +Private.SwipeTabBar {
> +visible: topToolBar.state == "small"

there should be a single instance capable of changing itself between the two 
states

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: EspiDev, squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, 
plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, 
davidedmundson

D28873: Add SwipeNavigator component

[Nathaniel Graham]

ngraham added a comment.


  When there isn't room to show all labels, eliding the labels or collapsing 
the inactive tabs to square-ish icons-only things that are still 
clickable/touchable would seem to make more sense to me. The above screenshot 
kind of looks like a visual glitch IMO.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: EspiDev, squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, 
plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, 
davidedmundson

D28873: Add SwipeNavigator component

[Carson Black]

cblack added a comment.


  In D28873#671043 , @ngraham wrote:
  
  > In that window, there's plenty of space for the component to expand 
horizontally. I would prefer to avoid scrolling tabs; their interaction is 
usually not great.
  
  
  It's collapsing because there isn't enough space to fit all of the labels.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, 
fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Nathaniel Graham]

ngraham added a comment.


  In D28873#671042 , @mart wrote:
  
  > If i make the window narrow enough, that's what happens
  >  F8319940: Screenshot_20200514_164118.png 

  >
  > perhaps it tabbar should scroll instead?
  
  
  In that window' there's plenty of space for the component to expand 
horizontally. I would prefer to avoid scrolling tabs; their interaction is 
usually not great.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, 
fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Marco Martin]

mart added a comment.


  If i make the window narrow enough, that's what happens
  F8319940: Screenshot_20200514_164118.png 

  
  perhaps it tabbar should scroll instead?

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, 
fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Carson Black]

cblack updated this revision to Diff 80804.
cblack added a comment.


  Adjust tab stylings

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28873?vs=80281=80804

BRANCH
  cblack/lateral (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D28873

AFFECTED FILES
  src/controls/Page.qml
  src/controls/SwipeNavigator.qml
  src/controls/private/SwipeTabBar.qml
  src/kirigamiplugin.cpp

To: cblack, #kirigami, #vdg
Cc: squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, 
fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Nathaniel Graham]

ngraham resigned from this revision.
ngraham added a subscriber: squeakypancakes.
ngraham added a comment.


  All right, you've convinced me.
  
  As for the appearance, we probably need for that to be defined using styles. 
IMO the material style should get this very google-looking appearance and we 
should come up with a different one for the Breeze desktop style. I'll admit to 
being partial to the macOS/ElementaryOS conjoined pill style--without the same 
degree of roundness, depth, and gradients, of course. @squeakypancakes came up 
with something I quite like in T13012#227542 
.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: squeakypancakes, ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, 
fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Niccolò Venerandi]

niccolove added a comment.


  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:
  >  F8249505: Screenshot_20200420_180317.png 

  
  
  I agree that that element has the same function on navigating views. I think 
that either this tasks uses that appearance on desktops (which would kill the 
"horizontal navigation"), or KCM should switch to whatever look this tasks ends 
up using (which I'm more in favor of). That's what I was trying to discuss in 
T11153 

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg, ngraham
Cc: ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, 
GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Nathaniel Graham]

ngraham added a comment.


  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.
  
  
  I feel like this needs discussion rather than being presented as a truism. We 
use tabbed views for non-editable views all over the place throughout KDE 
software and to be honest I don't see a problem with it. If we're going to 
declare this to be a bad thing and move towards changing it, we need to first 
start that discussion, agree on it, and agree on a solution.
  
  Would you like to open the Phab patch for this?

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg, ngraham
Cc: ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, 
GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Carson Black]

cblack added a comment.


  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.
  
  
  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.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg, ngraham
Cc: ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, 
GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Marco Martin]

mart added a comment.


  In D28873#652747 , @ngraham wrote:
  
  > Like you mentioned, don't we want to use the tabbed sidebar view thingy for 
that?
  
  
  i think it probably depends from the app both from tab numbers and semantics 
of the app?
  mayeb is worth to have written down use cases/scenarios with personas and 
what not to decide?
  (btw, ubuntu touch/ubports has an item like that that when the device 
switches from mobile to desktop, indeed goes from bottom bar to sidebar)

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg, ngraham
Cc: ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, 
GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Nathaniel Graham]

ngraham added a comment.


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

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg, ngraham
Cc: ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, 
GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Marco Martin]

mart added a comment.


  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
  
  so a final look like
   F8249539: Screenshot_20200420_182203.png 

  should be fine i think

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg, ngraham
Cc: ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, 
GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Nathaniel Graham]

ngraham requested changes to this revision.
ngraham added a comment.
This revision now requires changes to proceed.


  "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.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg, ngraham
Cc: ngraham, niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, 
GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Marco Martin]

mart added a comment.


  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
  >
  > F8241366: image.png 
  
  
  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:
  F8249505: Screenshot_20200420_180317.png 


INLINE COMMENTS

> niccolove wrote in SwipeNavigator.qml:55
> I think the tabbar should not be at the bottom on mobile. It's not necessary 
> to touch the control as swiping from any point of the page should change the 
> page, it is more visible when put at top, it is more consistent with kde and 
> not-kde applications and introduces a position inconsistency between devices 
> (touchscreen laptops should also be taken into consideration).

to me on mobile this is basically (or at least, is the only use i would have 
for such a control):
https://material.io/components/bottom-navigation

which yeah, should be at the bottom (and kirigami always had as a central point 
to have as much as possible controls, actions and chrome at the bottom for 
single hand use)

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Niccolò Venerandi]

niccolove added inline comments.

INLINE COMMENTS

> mart wrote in SwipeNavigator.qml:55
> different tabbars should really depend only on whether it's a mobile device 
> or not (and be at bottom if mobile): a very small window on desktop is not a 
> mobile app

I think the tabbar should not be at the bottom on mobile. It's not necessary to 
touch the control as swiping from any point of the page should change the page, 
it is more visible when put at top, it is more consistent with kde and not-kde 
applications and introduces a position inconsistency between devices 
(touchscreen laptops should also be taken into consideration).

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Carson Black]

cblack added inline comments.

INLINE COMMENTS

> mart wrote in Page.qml:238
> again, not convinced we should have this, seems a bit oddly specific

it's not uncommon for apps to have one page associated with an ongoing task.
examples:

- clocks app running a progress indicator in reverse to indicate a timer
- app store running a progress indicator on "updates/downloads" tab
- gallery/online drive app running a progress indicator on a tab to indicate 
syncing progress

> mart wrote in SwipeNavigator.qml:30
> perhaps any custom heading should be via a custom item (or component?) to put 
> as a property (of type qqc2.tabbar)

i don't see how that relates to wanting a larger (bigscreen-sized) header?

> mart wrote in SwipeNavigator.qml:55
> different tabbars should really depend only on whether it's a mobile device 
> or not (and be at bottom if mobile): a very small window on desktop is not a 
> mobile app

it's still nice to have a collapsed form of the tabbar for small screen sizes

> mart wrote in SwipeNavigator.qml:66
> this should be page actions? other actions? what is the exact use case?

global actions

> mart wrote in SwipeTabBar.qml:12
> QtQuickControls do have a TabBar control, instead of having a completely 
> custom control

I'm aware, but I went with a custom control for more control of the 
presentation and functionality.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Carson Black]

cblack updated this revision to Diff 80281.
cblack marked 5 inline comments as done.
cblack added a comment.


  Address some feedback

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28873?vs=80259=80281

BRANCH
  cblack/lateral (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D28873

AFFECTED FILES
  src/controls/Page.qml
  src/controls/SwipeNavigator.qml
  src/controls/private/SwipeTabBar.qml
  src/kirigamiplugin.cpp

To: cblack, #kirigami, #vdg
Cc: niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Carson Black]

cblack added a comment.


  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?
  
  
  Mmm, the point of this is to provide lateral navigation between pages, not 
arbitrary elements.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Camilo Higuita]

camiloh added a comment.


  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?

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Niccolò Venerandi]

niccolove added a comment.


  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
  
  F8241366: image.png 
  
  I think that this component //could// be a good solution, because we have a 
similar topbar on Maui:
  F8241370: photo_2020-04-16_10-22-45.jpg 
  Plus, this navigation view is really easy to replicate with toolbars (stupid 
wrong example, but you get what I mean):
  F8241377: Screenshot_20200416_102417.png 

  And this patch could add them for Kirigami as well.
  
  Of course, this assumes that some other stuff goes well:
  
  - Pressed buttons in toolbars should use highlight style (1px opaque line all 
around)
  - Possibly, buttons in toolbars should have an option to disable text if 
there's not enough space and they are not pressed
  - Apps should be okay with moving to a top centered mutually exclusive 
toolbuttons for navigating views
  - This patch should also use such highlight style
  - Possibly, Maui should drop his appviews component and use this one since it 
does the same thing, so this patch should coordinate with them and make sure 
this is feature-even
  
  We wouldn't get "swipe to change view" on qwidgets, but it's mostly for 
desktop so I think it's fine.
  
  For reference, I had done some consistency mockups in the past and this idea 
was already there:
  F8241385: image.png 
  
  A problem I see is that most application have a high number of views that 
won't fit horizontal space with labels (I'm looking at Skrooge, KMyMoney, 
Kontact, ...). Should they be fine with only displaying label for the current 
one? They probably would prefer a sidebar, which we currently don't 
consistently offer, so we end up with various inconsistent implementations.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: niccolove, mart, ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Marco Martin]

mart added inline comments.

INLINE COMMENTS

> Page.qml:223
> + */
> +property variant icon
> +

for consistency, should be a private/ActionItemGroup.qml (which mimics the 
upstream qqc2 api icon.name/source/width/height/color)

> Page.qml:238
> + */
> +property var progress: undefined
> +

again, not convinced we should have this, seems a bit oddly specific

> SwipeNavigator.qml:30
> + */
> +property bool largeHeader: false
> +

perhaps any custom heading should be via a custom item (or component?) to put 
as a property (of type qqc2.tabbar)

> SwipeNavigator.qml:38
> + */
> +property alias layerStack: stackView
> +

"layers", to have the same api of pageRow

> SwipeNavigator.qml:55
> +states: [
> +State {
> +name: "small"

different tabbars should really depend only on whether it's a mobile device or 
not (and be at bottom if mobile): a very small window on desktop is not a 
mobile app

> SwipeNavigator.qml:66
> +Kirigami.ActionToolBar {
> +id: actionToolBar
> +anchors {

this should be page actions? other actions? what is the exact use case?

> SwipeTabBar.qml:12
> +
> +RowLayout {
> +id: swipeTabBarRoot

QtQuickControls do have a TabBar control, instead of having a completely custom 
control

> SwipeTabBar.qml:37
> +if (index == columnView.currentIndex) {
> +return i18nc("Accessibility text for a page tab. 
> Keep the text as concise as possible and don't use a percent sign.", "Current 
> page. Progress: %1 percent.", Math.round(modelData.progress*100))
> +} else {

this is kinda outside of the scope of the control.
I guess you have an use case for this, but it shouldn't be a swiss army knife, 
just a tabbar: it's more complicated but at the same time there will always be 
people that miss a feature and will reimplement the whole thing for that.
I think it should just be easy to provide custom items for individual tabs, 
when needed (or just an item to be placed inside a tab, not sure)

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: mart, ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Marco Martin]

mart added a comment.


  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

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: mart, ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, davidedmundson

D28873: Add SwipeNavigator component

[Noah Davis]

ndavis added a comment.


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

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, 
ngraham, apol, ahiemstra, davidedmundson, mart

D28873: Add SwipeNavigator component

[Carson Black]

cblack added a comment.


  In D28873#649388 , @ndavis wrote:
  
  > What is the usecase for this?
  
  
  Apps that have shallow and primarily lateral navigation.
  
  > The progress tab's page highlight changes width with the percent of 
progress, correct? I think it looks wrong like that, unless I'm missing an 
important bit of context.
  
  Yes.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, 
ngraham, apol, ahiemstra, davidedmundson, mart

D28873: Add SwipeNavigator component

[Noah Davis]

ndavis added a comment.


  What is the usecase for this?
  
  The progress tab's page highlight changes width with the percent of progress, 
correct? I think it looks wrong like that, unless I'm missing an important bit 
of context.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D28873

To: cblack, #kirigami, #vdg
Cc: ndavis, camiloh, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, 
ngraham, apol, ahiemstra, davidedmundson, mart

D28873: Add SwipeNavigator component

[Carson Black]

cblack updated this revision to Diff 80259.
cblack added a comment.


  Add end-of-file newlines

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28873?vs=80258=80259

BRANCH
  cblack/lateral (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D28873

AFFECTED FILES
  src/controls/Page.qml
  src/controls/SwipeNavigator.qml
  src/controls/private/SwipeTabBar.qml
  src/kirigamiplugin.cpp

To: cblack, #kirigami, #vdg
Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, 
ahiemstra, davidedmundson, mart

D28873: Add SwipeNavigator component

[Carson Black]

cblack created this revision.
cblack added a reviewer: Kirigami.
Herald added a project: Kirigami.
Herald added a subscriber: plasma-devel.
cblack requested review of this revision.

REVISION SUMMARY
  SwipeNavigator is a component optimized for lateral
  page navigation rather than hierarchical page navigation.

TEST PLAN
  F8240680: test.qml  F8240681: 
ksnip_20200415-232411.png  F8240682: 
ksnip_20200415-232538.png 

REPOSITORY
  R169 Kirigami

BRANCH
  cblack/lateral (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D28873

AFFECTED FILES
  src/controls/Page.qml
  src/controls/SwipeNavigator.qml
  src/controls/private/SwipeTabBar.qml
  src/kirigamiplugin.cpp

To: cblack, #kirigami
Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, 
ahiemstra, davidedmundson, mart