Click–Drag–Release Dropdowns

If you have Chromium, go here and hold down left-click as you drag down to the option then release to immediately get what I mean. But if you do this in something like System Settings when say changing display resolutions you’ll find the interaction doesn’t work.

So I’m wondering if there’s some kind of setting that enables that interaction system-wide.

Operating System: NixOS 25.11
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.19.0
Qt Version: 6.9.2

That seems to be something that Chrome itself implements. Firefox has different behavior, requiring the button to be released before selecting again.

It’s definitely an option worth exploring, something possibly to bring up in Brainstorm.

I know you can use the scrollwheel/scroll gesture to go through the options on KDE pulldowns, but that doesn’t show the options all at once.

That’s what I figured for Chrome—it brings it’s own context menu and everything. Firefox seems to be trying to support the interaction but it kinda feels like Plasma needs to realize it needs to take over to do it’s part.

I’ll bring it up in the Brainstorm.

Post made. Unable to link, but /t/click-drag-release-dropdowns-the-brainstorm-one/40740

This is a definite Chromium thing. It’s an example of innovation vs consistency - and I think Precision is something to be prioritised.

I would argue that the click-drag-release model is more prone to accidental selection, which can prove very problematic when not just working in a sandbox.

Chromium’s prioritizing speed, Firefox/Plasma have a two-step method prioritizing precision and explicit confirmation.

  • Click to open the menu, then browse…
  • Click again to confirm.

Whilst browsing, you’d better not release that mouse button carelessly!!!

You would really wish to force a single interaction mode for all applications, regardless of specific behaviour chosen by each application or toolkit? Wouldn’t this create inconsistency?

I’d say Chromium is the odd-man-out here.

This works in KDE/Qt Apps, the click-mousemove-release on select box, that is.

IIRC that’s used in MacOS.

That’s also great for tablets/touch input.

It is more Gtk or Firefox at least in Plasma that is at odds.

That’s an Application/toolkit matter, the desktop (Plasma) has nothing to do with it.

1 Like

Haha ok, yes - just tried it with KWrite and I’m pleasantly surprised… I guess I just never thought to drag the selection before.

I have to add some nuance.

Excluding kirigami / Qt QML Controls as systemsettings. That’s an issue.

It is not yet reported AFAICT: search for kirigami bugs for mouse.

Please feel free to report it. This might a bug for Qt in ComboBox QML Type | Qt Quick Controls | Qt 6.10.0

Ah! I’ll get around to filing a report. And querying my system,

~> which systemsettings
/run/current-system/sw/bin/systemsettings
~> readlink -f /run/current-system/sw/bin/systemsettings
/nix/store/d7fmwq28fmz96jlk358kc2qnn1069nnm-systemsettings-6.4.5/bin/systemsettings
~> nix-store --query --references /nix/store/d7fmwq28fmz96jlk358kc2qnn1069nnm-systemsettings-6.4.5 | grep kirigami
/nix/store/zr325nqm9mb8sv4g7vqfhibv2cwh93af-kirigami-6.19.0

Looks like the bug is present on the latest tagged version. Overlaying with master instead…

{ pkgs, ... }:
{
  nixpkgs.overlays = [
    (final: prev: {
      kdePackages = prev.kdePackages.overrideScope (
        kfinal: kprev: {
          kirigami = kprev.kirigami.overrideAttrs (oldAttrs: {
            src = pkgs.fetchFromGitHub {
              owner = "KDE";
              repo = "kirigami";
              rev = "29dadde798531d33624a77045897760eb23b28df";
              hash = "sha256-DGucfFvaliuSMpQmlq49HdpRRHWy2Vy2uzCVitLfTuQ=";
            };
          });
        }
      );
    })
  ];
}

And rebuild (this time not making my laptop fall over with --max-jobs.)

sudo nixos-rebuild test --max-jobs 0 --builders "ssh://desktop.lan"

Though it’s going to take a bit to definitively say it affects master for the sake of it.

Can confirm it affects master too. Bug #510831 filed.

1 Like