Re: The Role of KInfoCenter

2020-02-03 Thread David Edmundson
I agree with your sentiment. Putting a command line tool in a window is useless.

I think there is scope for /something/ even if it's not the current state.

The system information page is really good
The energy page is really good (as a concept at least. The graph
implementation isn't something I can be proud of)

As for the PCI and USB devices:
I think it's a reasonable debugging level to want to find out if my
printer doesn't work because print-manager can't see it, or the
computer can't see the device at all.
That's something I can easily imagine a non-command-line user wanting to do.

I think the added value that we can bring over the command line tools
is reducing the noise and selecting what's useful.

So IMHO USB should hide the hubs, just have name and manufacturer of
devices and that's all.
Then it's actually useful again. I'd probably use that myself.

David


The Role of KInfoCenter

2020-02-03 Thread Harald Sitter
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