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
