- 1 Report problems
- 2 Conventions
- 3 TODO
- 3.1 Start page
- 3.2 Projects/Usability/HIG/Dialogs
- 3.3 Projects/Usability/HIG/ListView
- 3.4 Projects/Usability/HIG/Check_Box
- 3.5 Projects/Usability/HIG/SOU_Workspace/Two_Lists
- 3.6 Projects/Usability/HIG/Slider
- 3.7 Projects/Usability/HIG/Notifications
- 3.8 kdehig repository
If you found an area that was unclear or is not even covered in our HIG, tell us about it. We can be reached on the kde-guidelines mailing-list.
Following is a set of guidelines to ensure the HIG itself is consistent.
- Use the word Control, not Widget to refer to a user interface element. Rationale: "Control" is more widespread outside the UNIX community. It is also reasonable to expect more and more applications will be written using QtQuick and QtQuick controls in the future.
- Use check box and combo box, not checkbox or combobox.
- Figure out what to do of the legacy stuff (at the bottom of the page)
Recommendation should be checked
Check against recommendation.
Choose between either:
- In any other case, use the dual-list pattern because it allows users to easily see which items are selected at any point, without having to scroll through the available options
- Use a list box for multiple selections with more than five options.
Get a new type of check boxes for list views implemented: KCheckBoxes:
- KCB are flat (no frame, no shadow, no bevel) for clear differentiation from normal check boxes.
- KCB are hidden by default, that means when no list item is selected.
- KCB have a fade-in effect on mouse over to introduce themselves to users.
- KCB are transparent and therby clearly part of the list item.
- Legacy keyboard use applies to KCB as well. Thus, the whole item can be clicked to toggle option.
- Redo screenshots using Designer
- Fix missing page: list
- Move to Projects/Usability/HIG/Two_Lists? That is, drop "SOU_Workspace" from the url
- Redo screenshots using Designer
- Fix missing page: Selecting Items from a Pool
- Fix missing page: Picker Dialog
- Refresh page: it is copied from GNOME guidelines and contains references to figures we do not have
- Add screenshots
- Do not add controls to notification.
- Thomas: I would remove this. Adding action buttons is allowed in the API and has reasonable use cases, other controls simply cannot be added technically
- Do not override system settings.
- (remark: more specific)
- Thomas: Which settings do you mean here?
- Provide title and content text
- (remark: not precise enough)
- Thomas: guidelines regarding the wording of title and content are indeed very important. Maybe celeste can help here.
- Customize notification with the origin's icon.
- Heiko: word "origin" needs to be replaced; "icon" might be replaced by technical term
- Provide actionable information (e.g. "Low battery power" "Only 13 min (2%) capacity remaining. Please save your stuff now. Your system will get shut down soon.")
- should be according actual text
- Heiko: to be defined: Are all notifications configured in KCM? If not, how to separate?
- Kai Uwe: All notifications emitted through KNotify (ie. application has a notifyrc file) can be configured. Using the FDO notification dbus iface directly is discouraged. In 4.11 there's a configure button on notifications.
- Document how to use it
- Move it to KDE playground
- Integrate designer files from http://techbase.kde.org/File:HIG-UI-Files.tar.gz