This is a 1 - 1 translation of the QWidgets version of the Accessibility
KCM - Most of the functionality is there, and the layout is the same
with minor edits. We do need a better layout, this one does not behave
correctly in Qml (the tabs are too many and if a tab gets out of the
window, there's no way to click in it without resizing the whole window)
Depends on D23835
| No Linters Available |
| No Unit Test Coverage |
| Buildable 18915 | |
| Build 18933: arc lint + arc unit |
Thanks for taking this on Tomaz, Just throwing some ideas out but if it would help to have less tabs it might be useful to put all the keyboard features on one tab called Keyboard instead of the 3 it has now (Modifier Keys, Keyboard Filters and Activation Gestures) The top groupbox of Activation Gestures items could be moved to their respective groupboxes also so there are less groupboxes on the Keyboard tab than before on these 3 tabs.
I'll try - I don't like the amount of tabs, but maybe joining three tabs together is too much.
The Orca tab has only one option, there's configure notifications buttons twice. we need a bit of love there.
Visually, it looks exactly like the old one, but in qml.. which gives it several layouting problems
Since is tabbed (vdg should be contacted tough to see if they don't have a different option other than tabbed) it should use https://phabricator.kde.org/D23835 (which then would depend from)
all the things inside the tabs should then use a Kirigami.FormLayout
| kcms/access/CMakeLists.txt | ||
|---|---|---|
| 6 | kcm_access for compatibility with the other kcms | |
| kcms/access/package/contents/ui/Bell.qml | ||
|---|---|---|
| 28 | Shouldn't use groupboxes at all, but just FormLayouts with sections Kirigami.FormLayout {
Item{
Kirigami.formData.title: i18n("Audible Bell")
Kirigami.formData.isSection: true
}
QQC2.CheckBox { ....
....
Item{
Kirigami.formData.title: i18n("Visual Bell")
Kirigami.formData.isSection: true
}
QQC2.CheckBox { ....
} | |
this now depends on https://phabricator.kde.org/D23835 - There's an issue with saving (the save is not activated for some reason, I need to investigate.
Why is kcms/colors/CMakeLists.txt being changed? Looks unrelated.
As a general UI principle, whenever you have a group of controls that's mostly checkboxes, don't use formal section headers; instead, give the first checkbox a label by moving your Kirigami.FormData.label into it rather than putting it inside a separate Item or Separator.
Also often it's better to use whitespace instead of formal separator lines. It looks cleaner. Not always, but often.
So you would wind up with something that looks more like this:
In terms of a general UI design, I don't think tabs work here. There are too many tabs and they get cut off and look terrible with the default window size:
Instead, I think a better UI would be to have the tab chooser be a vertical list, like in the Notifications KCM:
| kcms/access/kcmaccess.h | ||
|---|---|---|
| 37–72 | Using KConfigXT will remove lots of boilerplate code (tons of property declaration + associated methods and easiest, load, save and defaults method). | |
| kcms/access/kcmaccess.h | ||
|---|---|---|
| 37–72 | Will look at it. | |
Lists such as these always need frames and backgrounds, like how it looks in the Notifications KCM. Just copy that.
It doesn't compile:
/home/nate/kde/usr/include/KF5/KNewStuff3/KNS3/DownloadDialog:1:10: fatal error: kns3/downloaddialog.h: No such file or directory
1 | #include "kns3/downloaddialog.h"
| ^~~~~~~~~~~~~~~~~~~~~~~Also we should be using the new QML-based GHNS dialog where possible, now that it's a first-class citizen.
A few changes still needed.
Also, in all the QML code we need to handle immutability of the settings (unfortunately that part can't be easily made magic like for the widgets). This would require for each control to have something like:
enabled: kcm.fooSettings.isImmutable("mySetting")
| kcms/access/kcmaccess.cpp | ||
|---|---|---|
| 177 | What @bport said, pass the parent to the ctor (will require adjusting the kcfgc files to get the corresponding ctors generated though). | |
| 213–214 | I think this override can completely go away. | |
| 221 | I don't think those calls to save are still needed. For sure you need to call the super class save() implementation though. | |
| kcms/access/kcmaccessibilitymouse.kcfg | ||
| 35 | Wouldn't an Enum be more suited here? | |
| kcms/colors/CMakeLists.txt | ||
| 28 | Why is there still changes in colors? | |
After squashing the commits to remove the broken history, arc diff opened a new revision.
https://phabricator.kde.org/D25375
| kcms/access/kcmaccessibilitymouse.kcfg | ||
|---|---|---|
| 35 | This i a spinBox with a range from 0 to 1000 in the original code, so I dont think an enum will be better there. | |