KDE Frameworks Documentation

[Ignat Semenov]

Hello Romain,

Thank you for the constructive answers. :)

>In a case like that, ask the maintainer(s). Usually, developers know the
>code of their program :) .
>Also, feel free to ask for help on IRC or through the bugzilla.

Sure, this can be done. But if every (possible) contributor asks the
maintainer, I'm afraid the latter will not be happy and probably will
not be able to answer all the questions. Then, I think that (non-human
:)) documentation is always better, you ask less questions, spend less
time, do not depend on IRC or any other ways of contacting the
original maintainer. IIRC in commercial software companies, you are
given documentaion as a newcomer, and while you may ask the project
leader in case you do not understand some pieces, they prefer interns
to figure out stuff themselves. This is just too simple and proves
that you can not think and derive things yourself, but in that case,
you're not a developer, that is, not an *engineer* at all! You may say
that docs are too simple as well, but no, you can not *ask* the docs,
only read them and then you still need to think yourself.

I think that:

1)The *apps* (besides the libs, which is pretty obvious, libs need
docs) need some documentation too. Like Dolphin, Digikam (ok,
extragear, I know, but still KDE), Konsole, ... and so on.
2)Both need *high-level design* documentation, not just the Doxygen or
any sort of API documentation, even the most extensive. A picture is
worth, well, you know, but not strictly a picture (like graphics), but
an explanation of how things interact and what they are responsible
for.

Now if the KDE oracles agree with these statements and proposals (none
have replied yet as far as I can see), I suggest that one of them
(Aaron? :) ) address the developers, most probably in a blog, and urge
them to create developer documentation for their apps besides the
regular Doxygen / hand-made API documentation (methods, modules,
variables).

Here goes the most important part:

We are in the process of transition to the so-called "KDE frameworks".
Some libs and modules are subject to change. Some code will get
rewritten and the API is definitely going to change. This is *the*
perfect moment to create the kind of documentation I'm talking about,
with diagrams, high-level design descriptions, MSDs and stuff. What do
you think?

Now on to the GDB part. KIO did not crash, there wa a bug somewhere in
the stack and I was trying to trace it. Actually, I think there was
one more problem:the plugins. How can you debug plugins? Like, there
is the kdeinit process, it has plugins, which do the stuff. Where is
the entry point or the main function or whatever is used instead of
it.

I think there was something else, that was a year ago :) I probably
got lost in the stack, there were too many layers.

Next, how can I debug asynchronous calls, like those in the Job API?

Regards,
Ignat Semenov

P.S. Could you please add me to the whitelist? I would like to keep
the inbox clean and empty, but avoid waiting for the moderator's
aproval. Is this possible?