Hi Aleix, On 01/07/2014, at 8:18 PM, Aleix Pol wrote: > On Tue, Jul 1, 2014 at 4:45 AM, Ian Wadham wrote: > On 30/06/2014, at 11:37 PM, Sune Vuorela wrote: > > On 2014-06-28, Ian Wadham wrote: > >> 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 DB= us, > >> and issues a message "Failed to communicate with kded. Make sure it is= running." > > > > In the kdelibs4.x-age, yes. kded should be running all the time no matt= er what. > = > In Linux and a KDE desktop manager, that is fine: kded4 is part of the st= ructure > of a KDE desktop manager. But in Apple OS X (or other desktop managers),= that > should not be a requirement, if KDE is to be truly portable. > = > Other desktop managers have their own ways of handling directory and file= changes, > battery level updates, device mounts, software update registration or wha= tever. So > maybe kded4 is not really needed at all on such platforms. > = > In particular, the absence of kded4 should not prevent a user from report= ing > a crash in a KDE application on Apple OS X or any other desktop manager, > should it? I don't think *anything* should prevent that=85 :-) > = > I do not think it is reasonable to ask the MacPorts developers to include > kded4 in startup procedures for every user, on the off chance that he or > she will use a KDE app sometime and that app will crash. > = > So I will proceed to patch around the requirement for kded4 in Dr Konqi in > Apple OS X, unless someone has a better idea or can point out some more > frequent and vital need for kded4 in a non-KDE desktop manager. > = > > Unfortunately, it isn't refcounting its users so it is running like for= ever. > = > = > Yes, I agree that with portability in mind, requiring a kded running with= some services kills the mood quite a bit. > = > Patches are welcome indeed, although I wonder whether it wouldn't be inte= resting to look into this on KF5 already, but maybe it just doesn't make a = difference. I think the code for KCrash and DrKonqi in KF5 is exactly the same ATM and has the same portability problems on Apple OS X (and maybe other desktops). As a heart-starter I will publish some patches soon, but they will a bit or= iented to Apple OS X, which is where I am working and seeing the problems. I did a little experiment which seems to show that using kcookiejar via kde= d4 is totally ineffective on Apple OS X, unless perhaps you are using Konqueror as a browser and KCM (is that the right name?) for desktop config (both bei= ng rather a stretch in an OS X environment). I went into settings for Firefox, my browser of choice, deleted all cookies= from bugs.kde.org and blocked cookies from bugs.kde.org. As expected, BKO wanted me to log in on every visit and did not remember my logins. Then I started kded4, followed by a KDE app, and I forced the application to crash. In Dr Konqi, kcookiejar ran OK but its check that I had cookies ena= bled on bugs.kde.org SUCCEEDED, even though I knew I had them disabled. No doubt cookies-enabled is the KDE default config and that is all kcookiejar = was checking, but such subtleties would be lost on the average user. I think the first route to try, for true portability of KDE apps, should be= Qt 4 or Qt 5. I do not know (yet) whether Qt can answer the question, "Do we have cookies enabled on QUrl(blahblah)?", but I have just discovered the QDesktopServices class, which has been in Qt since Qt 4.4 and is also in Qt 5. For example http://qt-project.org/doc/qt-5/qdesktopservices.html#openUrl wo= rks like a charm on Apple OS X. It opens a tab, in the browser you chose in th= at desktop's config, not whatever the default browser is in KDE's config. I intend to use QDesktopServices::openUrl() on Apple OS X in place of KToolInvocation::invokeBrowser( d->url.url() ); to open the BKO bug-report dialog in kdelibs/kdeui/dialogs/kbugreport.cpp. It works much better on Apple OS X and might work well on Linux too. Cheers, Ian W. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib= e <<