Bug 315702

Confirmed in master + 4.10 compiled from sources and kde 4.95 kubuntu 12.04

*** Bug 334934 has been marked as a duplicate of this bug. ***

Confirmed in 4.14.1 is also disabled. KDE libs from Ubuntu repositories.

openSUSE 20150129 (Tumbleweed) (x86_64)
Linux 3.18.3-1-desktop - KDE version 4.14.4

still the same in OpenSUSE....

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?

The Export button in the button bar.

Created attachment 95915 [details]
screenshot

Hmm. There is no export button (see screenshot)

Export function was removed Fri, 03 Apr 2015 with commit 
https://quickgit.kde.org/?p=kinfocenter.git&a=commit&h=8bdfcd16941a288c715bf638e4e6d81cc5aab1bb

Considering bug #334934, there is at least *some* interest in having this feature.

Should we continue using this bug as feature request?

Yes, makes sense

*** Bug 414953 has been marked as a duplicate of this bug. ***

What do you want to do with the export button? What's an example scenario where you'd see yourself using it?

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.

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?

(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.

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?

(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.

(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?

(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?

(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.

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!

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.

(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?

(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?

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).