Bug 315702

Summary: Re-add export function in kinfocenter
Product: [Applications] kinfocenter Reporter: Martin Walch <walch.martin>
Component: generalAssignee: Plasma Bugs List <plasma-bugs>
Status: CONFIRMED ---    
Severity: wishlist CC: adaptee, codestruct, dutchgigalo, giecrilj, lueck, nate, sitter, xcojack
Priority: NOR    
Version: 4.10.0   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: screenshot

Description Martin Walch 2013-02-23 20:36:54 UTC
The "Export" button in kinfocenter is always greyed out. I did not find an action that would activate the button.

This observation was confirmed by someone else using KDE 4.9.5 on Gentoo Linux and a third person using Kubuntu 12.04 with KDE 4.8.?

Bug #249830 already mentioned:
> There is a menu 'Export' which is disabled.
However, although that bug is RESOLVED/FIXED, I am not sure if the export button worked afterwards in 4.5.1.

Reproducible: Always
Comment 1 Burkhard Lück 2013-02-24 09:25:29 UTC
Confirmed in master + 4.10 compiled from sources and kde 4.95 kubuntu 12.04
Comment 2 Christoph Feck 2014-05-17 18:01:11 UTC
*** Bug 334934 has been marked as a duplicate of this bug. ***
Comment 3 xcojack@gmail.com 2014-12-21 12:08:32 UTC
Confirmed in 4.14.1 is also disabled. KDE libs from Ubuntu repositories.
Comment 4 André Verwijs 2015-01-30 20:51:23 UTC
openSUSE 20150129 (Tumbleweed) (x86_64)
Linux 3.18.3-1-desktop - KDE version 4.14.4

still the same in OpenSUSE....
Comment 5 Gregor Mi 2015-11-22 14:46:37 UTC
openSUSE 13.2, Plasma 5.4.3, KInfoCenter version 5.4.3: I don't see any Export button. Where is it supposed to be shown?
Comment 6 Christopher Yeleighton 2015-12-05 23:39:33 UTC
The Export button in the button bar.
Comment 7 Gregor Mi 2015-12-06 18:16:06 UTC
Created attachment 95915 [details]
screenshot
Comment 8 Gregor Mi 2015-12-13 17:08:42 UTC
Hmm. There is no export button (see screenshot)
Comment 9 Burkhard Lück 2016-08-11 07:44:43 UTC
Export function was removed Fri, 03 Apr 2015 with commit 
https://quickgit.kde.org/?p=kinfocenter.git&a=commit&h=8bdfcd16941a288c715bf638e4e6d81cc5aab1bb
Comment 10 Martin Walch 2016-08-12 07:31:35 UTC
Considering bug #334934, there is at least *some* interest in having this feature.

Should we continue using this bug as feature request?
Comment 11 Burkhard Lück 2016-08-12 08:17:17 UTC
Yes, makes sense
Comment 12 Nate Graham 2020-01-02 16:26:17 UTC
*** Bug 414953 has been marked as a duplicate of this bug. ***
Comment 13 Harald Sitter 2020-02-03 10:38:00 UTC
What do you want to do with the export button? What's an example scenario where you'd see yourself using it?
Comment 14 Christopher Yeleighton 2020-02-03 22:22:20 UTC
1. The Export button should allow me to share information about the configuration, capabilities and important content on my computer with a computer-savvy pal who can give me some advice about what needs to be changed to improve it.
2. The Export button should allow me to archive information for future reference, to be able to answer the question what important configuration changes were made between point A and point B, in case anything stopped working in between.
Comment 15 Harald Sitter 2020-02-04 10:03:17 UTC
Can you give a more concrete example for "configuration changes"?

In the archiving use case. How would you find out what changed between sample A and sample B? Some modules do have more than 100 lines of data they'd generate.

Is this about an "export all" feature or rather a per-module export feature?
Comment 16 Christopher Yeleighton 2020-02-04 11:34:00 UTC
(In reply to Harald Sitter from comment #15)
> Can you give a more concrete example for "configuration changes"?

Installing/removing a PCI card on the motherboard, changing RAM, disc drives, kernel version, network configuration…

> 
> In the archiving use case. How would you find out what changed between
> sample A and sample B? Some modules do have more than 100 lines of data
> they'd generate.

diff, I hope

> 
> Is this about an "export all" feature or rather a per-module export feature?

Export all would be enough.
Comment 17 Harald Sitter 2020-02-04 12:33:11 UTC
What's the added value of any of this over ls* command line tools then?

Or more to the point: the feature you describe isn't an export of the GUI, is it? It's a text dump of all information we can get about the system from anywhere (e.g. also lspci, vulkaninfo, glxinfo). Does that sound about right?
Comment 18 Christopher Yeleighton 2020-02-05 16:44:48 UTC
(In reply to Harald Sitter from comment #17)
> What's the added value of any of this over ls* command line tools then?

The added value is that command-line tools are harder to use and to discover.

> 
> Or more to the point: the feature you describe isn't an export of the GUI,
> is it? It's a text dump of all information we can get about the system from
> anywhere (e.g. also lspci, vulkaninfo, glxinfo). Does that sound about right?

I would expect the information displayed in the UI to be exported.
Comment 19 Harald Sitter 2020-02-06 09:42:27 UTC
(In reply to Christopher Yeleighton from comment #18)
> I would expect the information displayed in the UI to be exported.

Is there a rationale for that expectation? None of the described use cases would require the UI data, specifically, to get exported, would they?
Comment 20 Christopher Yeleighton 2020-02-06 12:14:19 UTC
(In reply to Harald Sitter from comment #19)
> (In reply to Christopher Yeleighton from comment #18)
> > I would expect the information displayed in the UI to be exported.
> 
> Is there a rationale for that expectation? None of the described use cases
> would require the UI data, specifically, to get exported, would they?

How about RAM?
Comment 21 Christopher Yeleighton 2020-02-06 12:17:24 UTC
(In reply to Harald Sitter from comment #19)
> (In reply to Christopher Yeleighton from comment #18)
> > I would expect the information displayed in the UI to be exported.
> 
> Is there a rationale for that expectation? None of the described use cases
> would require the UI data, specifically, to get exported, would they?

Of course you can export something different that the UI displays and the use cases will be met.  The only problem with this approach is that such behaviour will be unexpected and confusing.
Comment 22 Bug Janitor Service 2020-02-21 04:33:12 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 23 Harald Sitter 2020-02-21 11:08:05 UTC
Whoopsies. Forgot to follow up.

So, this will be a balancing act. While there was an Export button at some point. It actually did nothing. Ever. Certainly not for the past 10 years I've followed its history. The fundamental problem here is that native GUIs aren't really designed around text and more importantly not being converted to text. Because of that an export feature isn't simply a matter of adding a button, but needs to have all individual modules changed to be able to export themselves as text. That is a huge cost. What's more, it's a cost commitment. Any new UI feature, or new module, needs to be made in a way that allows it to be dumped as text. Don't get me wrong, it's entirely doable, but it requires code architectural considerations that otherwise would not be necessary, and that you usually do not make when building a GUI.
This is on top of the cost of modelling a not insubstantial amount of information more or less by hand (kinfocenter is about a quarter of the lines of code of dolphin, while bringing substantially less to the table). So making a module is already a lot of work because of the subject matter, adding export to that makes it probably +25% more work (+QA). It's no great surprise that the export feature wasn't actually ever implemented.

The way I see it there are three ways this feature could get implemented in a sustainable fashion:

a) the modules run some existing CLI tool to dump info to text. e.g. opengl runs glxinfo, pci runs lspci, usb runs lsusb... The drawback is that the data may not be representative, for the "advanced" modules like usb,pci,opengl it will be more or less though.

b) there is no per-module export feature. Instead it'd export anything and everything obtainable from various CLI tools but do so in a central place. The drawback is the advantage, it's in a single place and not per module so throwing this option together is less work.

The option a) would also go well with a restructuring of "advanced" modules. The pci module is huge in terms of code just modelling the PCI data and preparing it for the UI, one could replace it with a QItemModel representation of `lspci -mm` visualized in a simple listview and it'd be probably 1/4 the size. So, we'd be eliminating a lot of the hand modelling I lamented above, while also playing into the export-feature hand.

In any event, I do not see anybody from the existing Plasma team work on this, because it meets a very niche use case within an already somewhat niche component of the desktop experience. So, if someone wants to scratch their own itch, as it were, do pick an option. Be mindful of the maintenance cost of what you create.
Comment 24 Christopher Yeleighton 2020-02-21 11:38:50 UTC
(In reply to Harald Sitter from comment #23)
> Whoopsies. Forgot to follow up.
> 
> So, this will be a balancing act. While there was an Export button at some
> point. It actually did nothing. Ever. Certainly not for the past 10 years
> I've followed its history. The fundamental problem here is that native GUIs
> aren't really designed around text and more importantly not being converted
> to text. Because of that an export feature isn't simply a matter of adding a> The way I see it there are three ways this feature could get implemented in
> a sustainable fashion:
> 
> a) the modules run some existing CLI tool to dump info to text. e.g. opengl
> 
> b) there is no per-module export feature. Instead it'd export anything and
> 

c) ?

I guess that would be a per-model text output mode, i.e. it would print each individual piece of information out into an output file rather than placing it in the output pane, right?  And you consider this approach unmaintainable, right?
Comment 25 Christopher Yeleighton 2020-02-21 11:41:14 UTC
(In reply to Harald Sitter from comment #23)
> The way I see it there are three ways this feature could get implemented in
> a sustainable fashion:
> 
> a) the modules run some existing CLI tool to dump info to text. e.g. opengl
> 
> b) there is no per-module export feature. Instead it'd export anything and
> 

c) ?

I guess that would be a per-model text output mode, i.e. it would print each individual piece of information out into an output file rather than placing it in the output pane, right?  And you consider this approach unmaintainable, right?
Comment 26 Harald Sitter 2020-02-21 12:08:52 UTC
Yes, unmaintainable.
The model isn't placing anything, the GUI is pulling data out of the model and representing it via delegates. One could technically make a text dump that way, which is to say a completely separate read-only "UI" that dumps to text... Except not all modules are model based and not all models have DisplayRoles (i.e. singular text representations) as they instead need to be rendered by bespoke delegates (e.g. the battery model as I recall does that).