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?