Unify sidebar appearance
Open, Needs TriagePublic

Description

KDE software has a lot of different visual styles for sidebars, many ably illustrated in T11093: Improve Consistency across the Board:

Let's unify these to have the following characteristics:

  • White background (with default breeze color scheme; obviously it should follow the color scheme
  • Full width and height; top touches titlebar/tools area, bottom touches bottom window edge or status bar, left side touches left window edge, etc.
  • Single-pixel vertical line separates the sidebar from the content area on the right
  • When icons are large, they should be colorful: T10165: Large category icons should all be colorful

Furthermore, these three kinds of sidebars should be preferred when used to navigate application content:

  • Lists should be used when there are many possible views that would not fit when using a big icon.

  • Big Squares should be used when there are a limited number of possible views that usually fit the window heigh using big icons.

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

Thus, the following applications could need to be changed:

ApplicationCurrent stateDesired state
HeaptrackTabsList
KalgebraTabsBig squares
KbruchToolbar buttonsBig squares
SymbolEditorTabsBig Squares
KontactToolbar buttonsBig squares
KtorrentToolbar buttonsBig squares
KaffeineToolbar buttonsBig squares
SkroogeList in panelBig squares
KwalletmanagerTabsBig squares
Kmymoney?Big squares
KColorSchemeEditorTabsBig squares
Edit Window-Specific SettingsTabsBig squares
felixernst added a subscriber: felixernst.EditedJun 29 2019, 1:55 PM

There are two different scenarios for sidebars explained in T11093: Improve Consistency across the Board. Just to be clear: This task is only about the second one, right? I would tend to think these can be viewed as separate issues for now (roughly quoting @niccolove):

  1. Sidebars with many different pages that can be navigated through tabs - (we might want a separate task for this)
  2. Sidebars used to help the user navigate through the pages of an application - (this task)

So talking about the second kind of sidebar:

Let's unify these to have the following characteristics:

  • White background (with default breeze color scheme; obviously it should follow the color scheme
  • Full width and height; top touches titlebar/tools area, bottom touches bottom window edge or status bar, left side touches left window edge, etc.
  • Single-pixel vertical line separates the sidebar from the content area on the right
  • When icons are large, they should be colorful

+1.
I would think we only need two different sidebar appearances for this: The one used in System Settings when there are many entries and D20908: Redesign QML applet configuration windows when there are few.

ndavis added a subscriber: ndavis.Jun 29 2019, 4:20 PM

I would think we only need two different sidebar appearances for this: The one used in System Settings when there are many entries and D20908: RFC: Redesign QML applet configuration windows when there are few.

I will guess that sidebars should use the systemsettings-like list as sidebar vs configuration-like big icon above text when there are lots of elements. What about tabs on top? I'd say those should be used when they only change a part of the window and not the whole view (except in falkon of course), thus switching ksys to to big icon above text style, correct?

What about tabs on top? I'd say those should be used when they only change a part of the window and not the whole view (except in falkon of course),

Yes, in cases in which tabs can be replaced by sidebars without detriment we certainly should aim for unification to a single ui design. Aside from that I don't really have an opinion yet on when tabs should be used.

thus switching ksys to to big icon above text style, correct?

I think it could work for KSysGuard but I also think that it is in the awkward position of having exactly two tabs. This makes a sidebar seem a bit excessive with the benefits of having big icons for both pages (and unification).

What about tabs on top? I'd say those should be used when they only change a part of the window and not the whole view (except in falkon of course), thus switching ksys to to big icon above text style, correct?

Forget that, there's a much better definitions. Tabs should be used when the views are editable from the user, aka when the user can add, close and move tabs, such as in falkon, dolphin, etc. Also, tabs should be used when different views do not display different content: if you open multiple tabs on dolphin they are all about file viewing, while sidebars with big icons should be used when your are dividing different things in categories which should not change over time nor be user-editable.

niccolove added a comment.EditedSep 24 2019, 5:16 PM

What about tabs on top? I'd say those should be used when they only change a part of the window and not the whole view (except in falkon of course), thus switching ksys to to big icon above text style, correct?

Forget that, there's a much better definitions. Tabs should be used when the views are editable from the user, aka when the user can add, close and move tabs, such as in falkon, dolphin, etc. Also, tabs should be used when different views do not display different content: if you open multiple tabs on dolphin they are all about file viewing, while sidebars with big icons should be used when your are dividing different things in categories which should not change over time nor be user-editable.

If there was an agreement on that, those apps be changed:

  • Heaptrack
  • Kalgebra
  • Kbruch
  • SymbolEditor
  • Digikam
  • Kontact
  • Ktorrent
  • Elisa (list looks a bit different than other kirigami apps?)
  • Kaffeine
  • Skrooge
  • Kwalletmanager

Not sure on Kmymoney (does not work on my machine), but it seems right.

That definition doesn't really make sense to me. In an app's main window, we use tabbed interfaces primarily as a method to quickly switch between multiple self-contained documents or views, not different parts of the app's own main view. It wouldn't make sense to use tabs for Elisa's sidebar view selector, or Dolphin's places panel location selector, or similar user interfaces.

That definition doesn't really make sense to me. In an app's main window, we use tabbed interfaces primarily as a method to quickly switch between multiple self-contained documents or views, not different parts of the app's own main view. It wouldn't make sense to use tabs for Elisa's sidebar view selector, or Dolphin's places panel location selector, or similar user interfaces.

Wait, that's not what I mean :-)
(NB: I'm ONLY talking to main view right now, so not the subtask)
Right now there are three main ways to navigate the application (plus the various inconsistencies):

  • List

  • Big Squares

  • Tabs

I propose to define those use cases:

  • List: use when you have to navigate a good number of views that would not fit in big squares at a normal application size (such as, system settings and its long list or discover)
  • Big Squares: when there are top 5/6 elements, so it's possible to easily show big icons
  • Tabs: ONLY use when navigating multiple views of the same concept (not different pages with different stuff and different buttons, but generally folders/webpages/documents) that are user-editable (so you can create new tabs or close them).

This means, for example, that KSysguard should switch from tabs to Big Squares on the left, which I think really makes sense and would be more consistent. I am not proposing to "use tabs for Elisa's sidebar view selector" (as I said, tabs have a very different use case). I was more thinking to use Big Squares for Elisa but, now that I look better at it, there are probably enough elements to justify the list, so mistake on my side there :-) (it looks different from SySe or Discover list though). Regarding "Dolphin's places panel location selector", I would never propose tabs for sure, and the list is absolutely fine, especially since it's a panel with a bit different behaviour than the tipical application navigator on the left.

Yeah, that all makes sense to me.

@niccolove KSysGuard has tabs because you can add and edit as many views as you want.

@niccolove KSysGuard has tabs because you can add and edit as many views as you want.

TIL! I'll remove it from the list :-)

niccolove updated the task description. (Show Details)Sep 28 2019, 10:08 AM

I'm a bit unsure about many KCM using tabs though. Adding another list on the left would leave little space to the KCM since there are often already 2 lists on the left. On the other hand, you can open a single KCM and it doesn't make sense to have tabs there. Furthermore, Kirigami can hide lists if there is not enough horizontal space.

niccolove added a comment.EditedTue, Oct 29, 6:31 PM

In order to navigate through views, Maui uses this interesting concept instead of a sidebar:

This should be easy to implement with toolbars even on non-kirigami applications by using toolbars on top and will provide a very consistent look once we have T10201. I think this should be preferred on applications when having few elements rather than using big icons on the left, which can be used in popups, as they would waste quite a lot of horizontal space in applications.