Progress is good for us but bad for documentation
David Hurka
david.hurka at mailbox.org
Mon Jun 14 13:00:42 BST 2021
Hi Frederik,
here is my report about a negative experience with existing documentation:
> So what to report? Documentation that ...
> - [...]
> - has holes in it. For example a tutorial where you suddenly think,
> you skipped an important step.
> - you wish was there but you could not find it.
When I tried to understand KXmlGui an KParts (about 15 months ago?), I felt
left alone from the documentation.
KXmlGui:
KXmlGui explains itself as user configurable main windows (toolbars,
shortcuts), which should be enough for an introduction. But KXmlGui docs
didn’t give me examples how to use it. Just creating a KXmlGui main window and
putting a KXmlGuiClient in it didn’t work as easy as setting the main widget
of a QMainWindow. My experiment application always crashed at startup.
Here I would expect some minimal working examples.
It also misses an introduction about merging multiple KXmlGuiClients to one
user interface.
KParts:
KParts didn’t tell me what the whole framework is good for. After reading the
documentation, I doubted that a KPart is anything more than a KXmlGuiClient
with another name or even a QWidget with a list of actions. Why not just
instantiate a QWidget derived object from a library, and put that QWidget in
my main window?
Here I would expect an introduction why I should use KParts.
Only KReadOnlyPart and KReadWritePart made some sense for me. These were able
to provide reading and writing files through KIO just through the openUrl()
and saveAs() methods. And Konqueror can search for a KReadOnlyPart that allows
to open a specific document type, and use this part through a common API.
Cheers, David
More information about the kde-devel
mailing list