[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=315702

Nate Graham  changed:

   What|Removed |Added

 CC||n...@kde.org
   Assignee|hubn...@gmail.com   |plasma-b...@kde.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Harald Sitter]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #26 from Harald Sitter  ---
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).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Christopher Yeleighton]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #25 from Christopher Yeleighton  ---
(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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Christopher Yeleighton]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #24 from Christopher Yeleighton  ---
(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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Harald Sitter]

https://bugs.kde.org/show_bug.cgi?id=315702

Harald Sitter  changed:

   What|Removed |Added

 Status|NEEDSINFO   |CONFIRMED
 Resolution|WAITINGFORINFO  |---

--- Comment #23 from Harald Sitter  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Bug Janitor Service]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #22 from Bug Janitor Service  ---
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!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Christopher Yeleighton]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #21 from Christopher Yeleighton  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Christopher Yeleighton]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #20 from Christopher Yeleighton  ---
(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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Harald Sitter]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #19 from Harald Sitter  ---
(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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Christopher Yeleighton]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #18 from Christopher Yeleighton  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Harald Sitter]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #17 from Harald Sitter  ---
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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Christopher Yeleighton]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #16 from Christopher Yeleighton  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Harald Sitter]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #15 from Harald Sitter  ---
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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Christopher Yeleighton]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #14 from Christopher Yeleighton  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Harald Sitter]

https://bugs.kde.org/show_bug.cgi?id=315702

Harald Sitter  changed:

   What|Removed |Added

 Status|CONFIRMED   |NEEDSINFO
 Resolution|--- |WAITINGFORINFO
 CC||sit...@kde.org

--- Comment #13 from Harald Sitter  ---
What do you want to do with the export button? What's an example scenario where
you'd see yourself using it?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=315702

--- Comment #12 from Nate Graham  ---
*** Bug 414953 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 315702] Re-add export function in kinfocenter

[Martin Walch via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=315702

Martin Walch  changed:

   What|Removed |Added

Summary|Export button in|Re-add export function in
   |kinfocenter is always   |kinfocenter
   |inactive|
   Severity|normal  |wishlist

-- 
You are receiving this mail because:
You are watching all bug changes.