https://bugs.kde.org/show_bug.cgi?id=315702
Harald Sitter <sit...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDSINFO |CONFIRMED
Resolution|WAITINGFORINFO |---
--- Comment #23 from Harald Sitter <sit...@kde.org> ---
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.
