System settings animation

[Duncan]

René J.V. Bertin posted on Sun, 18 Aug 2024 02:33:40 +0200 as excerpted:

> On Saturday August 17 2024 14:36:27 Dave Close wrote:
> 
>>But animation in system settings has annoyed me for a long time and
>>still does. It ignores that I've turned animation off everywhere I can.
>>Moving from one item in the list to the associated page and back again
>>insists on sliding the page, slowly. Is there a way to disable this
>>behavior and return to a sane presentation?

FWIW... While I don't have the no-animations "compulsion" of the OP, being 
on the autism spectrum of course I have various compulsions of my own 
including the "need" to highly customize so it works /just/ they way I 
want (thus the fact that I run kde plasma on gentoo's distribution of gnu 
linux, all three known for being more highly customizable than many/most 
of their peers), so I well understand the importance of being able to set 
these to work as one wishes/needs.

> It's been over 5 years that I last updated the systemsettings package
> I'm still using (ahhhh, the stability, tranquility and productivity you
> can enjoy spending your time working *with* your system rather than *on*
> it ;)).

As you know (given that we're both list regulars) our personal preferences 
are polar opposite in that regard. =:^)  I not only run gentoo ~arch (aka 
"unstale" aka "unstable") for faster updates, but run most of kde/plasma 
as well as other selected applications built from live-git, because it's 
far easier to track down bugs (to report) and unwanted new "features" (to 
occasionally patch back out at least until they're less bbugged, or modify 
to my own ends, given the git-commit pointer as to where to do so) at the 
individual commit level than it is even consistently running the latest 
release, let alone something months or years and many releases outdated, 
as is the case with many sta(b)le distro options (and it seems you're 
beyond that, running your own old versions without feeling the need to 
update, just as strongly as I feel the need/compulsion to be current).

But because we're both out of the norm tho on opposite ends we both need 
deeper than average knowledge of the subject area, and I can  hope that 
over the years here you've come to respect my knowledge of the subject 
area at the latest bleeding edge just as I've come to respect yours at the 
sta(b)le trailing edge. =:^)

> I do recall getting a hissing fit about it trying to shove a
> QML-based UI down my throat (after updating to v5.13.5, which I'm still
> using).
> I'm not entirely certain how I got it back to a proper, qtwidget-based
> UI. It may have been as simple as re-selecting the icon-based interface,
> it may also have required getting rid of (not building) the
> `systemsettings_sidebar_mode` plugin.
> 
> Of course I have no idea if any part of K??6 Plasma6 is still
> widgets-based or if the goal is to migrate everything to QML.

As I understand it after running kde/plasma live-git and closely following 
development for some years now...

While the goal isn't to migrate /everything/ (particularly for old code, 
but for new apps to eventually replace the old it's a more open question) 
to qml, in large part because that's basically high-level scripting and 
for some use-cases the performance is simply not acceptable, the general 
deliberate policy does seem to be to migrate to qml where it's not going 
to be a performance or ongoing maintenance issue, because while the 
initial port is a pain, it /usually/ results in far less complex and more 
maintainable code going forward.

Additionally, native code must of course be built for and in many cases 
coded for a specific platform, while qml code tends to "just work" across 
most platforms qt is supported on -- there's far less "#ifdef-ing" when 
targeting GNU-Linux vs. Android Linux vs. plasma-mobile vs. the open-
source BSDs vs. the semi-proprietary AppleOS vs. the proprietary MS 
Windows vs. ... , and with qt6/frameworks6/plasma6/gear24+ primary 
targeting emphasis for new apps in particular tends to be at least plasma-
mobile as well as the various free desktops, with secondary targets of 
android/aos/msw depending on the app and its author preferences.  
Restating, for qt6/kde-frameworks6/plasma6 and beyond, qml tends to be 
strongly favored where it's performant "enough" because it tends to "just 
work" across qt-supported platforms without much porting or ifdef-ing.

Of course what we're specifically talking about here is plasma 
systemsettings (and its kcms, kde control modules, a legacy term but there 
it is), which is by definition customization and thus not performance-
critical hot-path.  That makes it and all its component kcms by 
definition /prime/ targets for rewriting to qml, particularly the ones 
that are needed on plasma-mobile too, and you'd surely find your plasma 
systemsetting bare indeed if you tried to go qtwidget-only with plasma6 
(which I doubt is even possible) as you did with plasma5.  And of course 
there's only the sidebar display format now, the icons interface option is 
long gone.

> Here's an idea: all the KCMs shown in the systemsettings application
> must have .desktop files. Copy or symlink the ones you want to a folder
> of your own, or create a submenu in your favourite launcher for them.
> Selecting one from there should launch `kcmshell6 $kcm` with as much or
> as little eyecandy as you configured.

I have in fact done just this, except I don't bother with the *.desktop 
files at all, instead directly using kcmshell6 $kcm, with $kcm substituted 
as necessary, for the commandlines.

Hint: In konsole (or your $term of choice), kcmshell6 --list will spit out 
a list of the available kcms.  Most will be prefixed kcm_, but the kcm_ 
bit seems to (usually? always?) be optional.  So for example kcmshell6 
(kcm_)mouse should invoke the mouse kcm with or without the kcm_ prefix.  
The two exceptions --list displays here are kcmspellchecking, no underline 
in the prefix but simply spellchecking appears to work as well, and 
kwincompositing, no kcm prefix at all and it does not appear to work when 
called as kcm_kwincompositing.  (In fact, since I'm on wayland via 
kwin_wayland not X via kwin_x11, running kcmshell6 kwincompositing gives 
me an empty kcm window as well, but running kcmshell6 kcm_kwincompositing 
give me an error to the effect that it can't find that kcm, that the 
unprefixed version does not, so it seems to find and load the kcm without 
the prefix just as it's listed, but there's just nothing for the kcm to 
configure on wayland.)

Also note that there are a few kcms available via direct kcmshell6 lauch 
that aren't available through plasma's systemsettings.  
kcm_qtquicksettings, for example, which displays a caution when run to 
only change settings if you know what you are doing.  (I just found it 
using --list while writing this and was curious so ran it; I've not 
experimented -- yet -- but knowing how to run it again without running it 
via the plasmashell menu if messing with it screws up plasmashell enough 
so it keeps crashing so I couldn't get to it that way, could definitely be 
useful!!)

But a caveat... at least with plasma6 I don't believe the kcmshell 
commandline route will entirely eliminate /all/ kcm animations.  For 
instance, when running kcmshell6 (kcm_)kwinrules is I believe entirely 
qml-based (and has been since 5.something).  You may or may not have any 
window rules setup, but while it's a single window listing the rules, 
hitting the edit button (the pencil) for an individual entry will animate 
a slide-in of that entry.  I've not tried disabling animations here, but 
from the OP's description of behavior when he did, I'd expect that to 
still animate regardless.

But direct kcm launches should still be /less/ animations than 
systemsettings, which should be better for him. =:^)

(Meanwhile, FWIW my custom menu/launcher of choice is pdmenu, run in 
kconsole as it's a slang-based TUI, not CLI or X/wayland GUI.  I have 
pdmenu's colors set and use a custom transparent konsole profile, calling 
konsole with options to hide the toolbar, tabbar, etc as well as to launch 
it with that profile, plus I have a kwin window rule for it to hide the 
titlebar and border, so it's transparent except for the TUI menu itself, 
making the menu appears to popup as its own borderless text-based window.  
And I have an entire "ecosystem" of custom pdmenus setup with the a main 
menu and initial children each configured with their own (kde level) 
hotkeys.  This includes a general "config" menu with a "kde" submenu, 
which has an "all" entry which launches plasma systemsettings, along with 
all my individual kcmshell6 $kcm entries.  Given this pdmenu "ecosystem" I 
rarely invoke the normal kde app menu unless it's just to explore options 
I use seldom enough that I don't have a direct hotkey setup for them or a 
pdmenu entry, and even then if I know the name (say for something like 
kruler or kcharselect), I'll tend to use krunner to run them by name 
instead.  So I might open the main plasma launcher maybe a couple times a 
month if that?  In any case it's definitely less often than I update it 
since I'm running kde from live-git!)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman