Create Task
Maniphest T8316

Categorize components
Open, HighPublic
Actions

Description

Categorize components that are described in the HIG regarding where they are available or should be used.

Apps Workspace
Kirigami qWidgets Plasma Comp. DesktopMobile
xxxxx
Primary action buttonxxx
Secondary(left/right) action buttonsxxx
Check boxxxxxx
Combox boxxxxxx
Command linkxxxxx
Context menuxxxx
Date and time pickersxxxx
Drop downxxxxx
Global drawerxxx
Group box
Line editxxxxx
List viewxxxxx
List Itemxxxxx
SwipeListItemxx?x
Loading and progressxxxxx
Menu barxx
Menu button (1)xxxx
Push buttonxxxxx
Radio buttonxxxxx
Sliderxxxxx
Spin boxxxxxx
Split buttonxx
Splitterxxxxx
Status barxx
Tabxxxxx
Table viewxxxx
Text editxxxxx
Toggle buttonxxxxx
Tooltipxxxx
Tree viewxxxxx
  1. Menu button: Not a control on its own, but a button and a menu. Either move it to pattern or remove it

Related Objects
Search...

StatusAssignedTask
 OpenfabianrT8316 Categorize components
 OpenNoneT8146 Overall structure
fabianr created this task.Mar 26 2018, 9:59 AM
fabianr triaged this task as High priority.
ngraham added a subscriber: ngraham.Mar 26 2018, 12:51 PM

Desktop Kirigami apps can't have menubars, context menus, and statusbars?

mart added a subscriber: mart.Mar 26 2018, 1:51 PM

there are qqc2 components for all of them...
thing is, it depends on if we want them, the decision at the beginning of the design phase, was a conscious "let's get rid of them" (which i hope it stays, especially for menubars) also because the action tree in the global drawer directly conflicts with the concept of menubar

fabianr added a comment.Mar 26 2018, 2:03 PM

We can remove the x for "Status bar" "qWidgets" too, just like I removed all the "x" for Group box, even so technical the control still exists?

ngraham added a comment.Mar 26 2018, 2:04 PM

A problem right now is that Kirigami apps on the desktop often don't really feel like native desktop apps IMHO. One contributor is the lack of menubars and context menus.

The question is, do we want Kirigami apps on the desktop to feel like Kirigami apps, or like KDE apps? Right now I feel like there's a bit too much of the former.

fabianr updated the task description. (Show Details)Mar 26 2018, 2:07 PM

I added the "x" for context menu. Now it is in the same as the https://phabricator.kde.org/T8271 , but both might be wrong?

fabianr updated the task description. (Show Details)Mar 28 2018, 1:21 PM
ngraham added a comment.Mar 28 2018, 1:38 PM

Kirigami and Plasma have menu buttons.

fabianr updated the task description. (Show Details)Mar 28 2018, 1:45 PM
fabianr updated the task description. (Show Details)Mar 28 2018, 1:50 PM
colomar added a comment.Apr 5 2018, 2:03 PM

Some questions/feedback

  • So do we have context menus in Kirigami / QQC2 right now or not?
  • And what about spin boxes? Is there actually a QQC2 for those? Apart from that technical question: I would not recommend them on mobile, their buttons are too small for touch.
  • Is there a traditional tooltip in QQC2?
  • Last time I talked to people, there was no treeview in QQC2. Is there one now?

Apart from that, it looks good to me.

mart updated the task description. (Show Details)Apr 6 2018, 9:20 AM
mart updated the task description. (Show Details)Apr 10 2018, 8:11 AM
ngraham added a comment.Apr 10 2018, 1:15 PM

You don't swipe things with a mouse or touchpad, so SwipeListItem needs to support a more desktop-appropriate interaction metaphor, per the Kirigami HIG: https://community.kde.org/KDE_Visual_Design_Group/KirigamiHIG/Principles/OptimizedConverence

Kirigami is not about simple "responsive" user interfaces, though (i.e. those which just adapt their layout a bit), but really optimized ones. For example, "pointing device + keyboard" UIs should use mouse-over/hover effects to reveal inline controls, whereas touch UIs should use touch gestures.

See https://bugs.kde.org/show_bug.cgi?id=364383

fabianr updated the task description. (Show Details)Jun 22 2018, 4:06 PM