Hi guys, When fixing some bugs in the KCrash-DrKonqi sequence on Apple OS X, I have come to a point where Dr Konqi attempts to call kded4, using DBus, and issues a message "Failed to communicate with kded. Make sure it is running."
This is actually a great advance: it has rarely been possible to run Dr Konqi and get even a backtrace on Apple OS X until now. However progress towards reporting the crash. on bugs.kde.org, is blocked at the point when you log in to BKO. Before fixing this, I have some questions. 1. KDED4 runs all the time on a KDE desktop I believe, judging from what is said on http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/, but does it need to on other desktops, such as Gnome, Windows and OS X? ATM it never runs in MacPorts with KDE apps on Apple OS X, and AFAIK that has had little effect on running KDE apps there. 2. The reason Dr Konqi calls KDED4 is to load KCookieJar and check whether cookies are enabled for bugs.kde.org on this user's system. If they are not, Dr Konqi will not process the bug report any further. Is this approach really necessary? 3. AFAIK cookies are needed on BKO only so that the user can stay logged in to BKO if he or she wishes. So would it be enough just to issue a warning message about that and move on, if KDED4 or KCookieJar or the required cookies are unavailable? 4. If cookies are enabled, is there any way to attempt to connect immediately to bugs.kde.org from Dr Konqi and skip entering the ID and password, in case the user is already logged in there? I am just wondering what is the best way to fix these issues and make proper crash-reporting possible in KDE applications on Apple OS X. Cheers, Ian W. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<