The Role of KInfoCenter

Harald Sitter sitter at kde.org
Mon Feb 3 11:11:57 GMT 2020


Ahoi!

I was hoping we can have a bikeshed discussion about KInfoCenter :)

The past couple of weeks I've been spending some time on KIC and what
became apparent quickly is that I have not the faintest idea who the
application is for, or when/how one would use it. That makes it nigh
impossible to say whether a wish fits into the vision of the
application, or even where to take the application in the future in
general.

For example the OpenGL module....

It's a treeview of data you'll approximately find in glxinfo (+some
additional data on EGL and GLU). Costs about 800 SLOC and requires
next to no maintenance. On paper that's grand.
But who of our design personas would use it for what purpose? [1]
Who would use it for anything other than maybe looking at the backing
kernel module?
Or perhaps more importantly: even if we assume that **someone** who's
not necessarily part of the personas finds this information useful:
Why ever would they use the GUI to look at that when they can get this
information out of the glxinfo tool which then also allows them to
apply processing to the output, to, for example, grep for what they
want to know?
The GUI has all the disadvantages of the CLI tool (dump of all
remotely extractable information even when 99% is useless noise)
without any of the advantages that you naturally get with from being
on  a terminal (piping every which way to mold the data). So, what is
it good for?

This applies to most modules really. Take a look at the Interrupts
module or the PCI module. I don't see a casual user going there (cause
it's daunting technobabble), a power user likely wouldn't go there
either (cause it's inferior to terminal tools), that kinda leaves the
in-betweens. But why would they look at this data? What would they do
with it? What's the use case?

In lieu of an explanation for KIC's "reason to be", as it were, what
do we think KIC should be?
Why shouldn't its useful functionality not part of system settings, or
possibly ksysguard? For example the new smb module I wrote [2] could
easily have 'add/remove share' and 'mount/unmount share'
functionality, it'd be way more useful that way, but then it's
suddenly a settings module... Meanwhile the advanced memory
information of the Memory module seems to largely replicate
information we already have in ksysguard, and when looking at this
data it entirely stands to reason that if I see that I'm low on RAM I
may want to know what is eating it and possibly kill it.

In short: KIC makes me go "???" and, thinking back, it always has.
It's nice to look at and feel like a hacker but its functionality
eludes me.

(looking at it and feeling like a hacker may be entirely worthwhile,
but then I'd revisit the code cost of the modules and make them text
views of CLI tool output directly)

[1] https://community.kde.org/Plasma/Workspace_Sprint/Personas
[2] https://phabricator.kde.org/file/data/csr6d4o5h5cdl23zqm6h/PHID-FILE-tij25pcl4cajzm4bfdbo/Screenshot_20200131_132853.png

HS


More information about the Plasma-devel mailing list