The list had a few problems, notably an erratic sorting that randomly change during and after searching for a layout.
While at it, refactor some code and port the models to C++.
The use-case for this has passed. Most devices appear as mass storage
devices.
The UI is not up to the expectations of something we would allow in
Plasma if it was introduced today. The end goal is for user to set
custom commands via an incredibly complicated UI that requires the user
to know how to use Solid predicates syntax.
At most it saves a few clicks it does not solve any unique problems on
it's own.
The code in the Device Notifier applet is left unchanged as actions can
still be shipped by applications or written manually. This brings it in
line to dolphin service menus.
This was discussed at the last Plasma sprint in Graz.
Searching System Settings for "drag and drop" (or "drag", "drop")
lists the Mouse page, which has no drag-and-drop setting, and does not
list General Behavior, which has the "Drag and Drop" group that
controls what happens when files are dropped.
BUG: 518455
Indent them to the level of the corresponding checkbox's text.
Make this work also for right-to-left layouts.
Modeled after "Disable while (...)" checkboxes in Touchpad KCM.
`contentItem` padding works in Breeze, but cannot be relied upon;
the Union style does not set it in the same way.
Using indicator width plus spacing is more widely compatible.
Also, use "mirrored" property for more compact phrasing.
Amends d6d785e4a1
children[1] is undefined while the grid is created, so every time the
page opens it logs "Unable to assign [undefined] to QQuickItem*". The
Repeater's onItemAdded already makes the first item the buddy.
Use raised buttons and alternating backgrounds, as recommended by ths
HIG; this helps distinguish interactive buttons from list items'
decorative icons, and helps the eye associate the controls on the right
with the text and icons on the left.
If some of their names are longer than others, the labels become
multi-line strings. In such a circumstance, these will default to center
alignment (which looks bad) unless we specify something else.
Authorization for set-time implies set-ntp and set-timezone, if acquired first
then the user will only see one polkit dialog. However ntp needs to be disabled
first before the time can be changed. Unfortunately due to deficiencies inside
KAuth with the Polkit backend it's not possible to authorize an arbitrary action,
so Polkit-qt is used for this. The code "executes" still a KAuth action to make
use of the side channel for parent window and activation token to our agent,
but since the action doesn't have a helper will actually not execute anything.
It can take an arbitrary amount of time until the user answers authorizes
the change, during that time in the real world keeps running, the set time
by the user doesn't change once set. Calculate the diffrence in time beforehand
to keep it as close as possible to what the user wanted.
### Reason for the change
Some of the references in the QML were undefined, so the refreshInputSequence
function would not get called from the root.onSettingsRestored connection,
and in the onGotInputSequence handler, the button int was undefined, and
would silently become a 0 when going to C++.
So the button settings would (1) not change the correct button code, and (2)
both the pen buttons would show the same setting, despite trying to get them
to be different.
The problem with refreshInputSequence also existed in the pad button settings,
but there at least the setting would be applied, it's just that the display of
the setting would not refresh properly.
This change qualifies and rebinds the properties as needed, and all of that works now.
### Test plan
Try to set stylus buttons, ensure (through adding logs) they they get sent to the correct button code (not 0), and that the two stylus buttons can be configured independently.
Try to set pad buttons, ensure that the change you make doesn't seem to disappear after exiting the popup.
### Bugs fixed
I looked through all open bugs against systemsettings > kcm_tablet, and somehow this does not appear to have been reported yet.
<!-- Don't remove or edit anything below this line. -->
Middle-click by pressing both bottom corners only works if the
radio button setting "Right-click by: Pressing bottom-right corner"
(a.k.a. `clickMethodAreas == true`) is enabled.
It does not work if instead, the alternate radio button setting
"Right-click by: Pressing anywhere with two fingers"
(a.k.a. `clickMethodClickfinger == true`) is enabled.
In the latter case, disable the checkbox
"Left and right buttons: Press both simultaneously to middle-click".
This is still somewhat awkward as a radio button group further down
in the page determines the state of a checkbox much higher up.
We may at some point redesign this in a more fundamental way.
Until then, this commit ensures that at least we don't show an
option as working when it's actually ignored.
Also, hide this checkbox entirely if it's not supported by the
touchpad at all. Other unsupported settings get hidden too,
no reason to treat this one differently.
Always show subtitles for the right-click radio buttons, to avoid
confusion about controls jumping around while clicking them.
Remove the conditionally visible pair of radio buttons titled
"Middle-click by: Pressing {bottom center, left/right}". An option
further up already provides access to the same setting, called
"Press both [l&r buttons] simultaneously to middle-click".
On the other side of conditional visibility, remove the checkbox
"Middle-click by: Pressing anywhere with three fingers"
as the corresponding radio button subtitle already mentions this.
Being permanently disabled, it only existed to explain the behavior.
In the "Tapping" section below, move "middle-click by (...)" text
of "Two-finger tap" radio buttons from parentheses into subtitles.
This lines up visually with the "Right-click by..." radio button
group further up.
The cognitive dissonance of not having two "Right-click by..." groups
work in the same way (clicking vs. tapping) remains for now.
kcm_keys has some layouting issues at very small window sizes:
- The column headers (Default/Custom shortcuts) always take up the full
width. This works fine in most languages, but breaks for the usual
culprits of volumnious verbiage, like German and Russian
- Somewhat similarly, the shortcuts themselves always take up their full
single-line width. This works fine almost all the time, but can break
if you have some four-modifier monstrosities defined (as we
unfortunately do in e.g. emojier, for technical reasons). It's even
worse if your language has some long key names like "Leertaste", or
constraints from long column names.
In these cases we may end up with overlapping bits, and parts of the
text or even actual buttons that are off-screen.
In principle, we could fix this just by adding Layout.fillWidth in a
couple of strategic places and allowing things to elide/wrap as
necessary. But this doesn't always yield the best results because of the
layout structure.
kcm_keys has two columns here, one left-aligned and one right-aligned.
Visually, it does not make much sense to require that the header and the
contents have the same width, as it will yield unused space and
unnecessary elision.
So we switch from a RowLayout of ColumLayout to a ColumnLayout of
RowLayouts, and set fillWidth and elide as necessary.
This makes the contents always fit at all window sizes, and elides
things only if it's really necessary and we can't take unused space from
elsewhere. Some situations are still not the utmost of what is
potentially achievable, but we're talking absolute edge cases and
they're at most a little awkward, rather than obviously broken.
BUG: 525725
FIXED-IN: 6.8.0
