Hi Aleix, On 01/07/2014, at 8:18 PM, Aleix Pol wrote: > On Tue, Jul 1, 2014 at 4:45 AM, Ian Wadham <iandw...@gmail.com> wrote: > On 30/06/2014, at 11:37 PM, Sune Vuorela wrote: > > On 2014-06-28, Ian Wadham <iandw...@gmail.com> 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 DBus, > >> 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 matter > > what. > > In Linux and a KDE desktop manager, that is fine: kded4 is part of the > structure > 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 > whatever. So > maybe kded4 is not really needed at all on such platforms. > > In particular, the absence of kded4 should not prevent a user from reporting > 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… :-) > > 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 forever. > > > 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 > interesting 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 oriented 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 kded4 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 being 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 enabled 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 works like a charm on Apple OS X. It opens a tab, in the browser you chose in that 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 unsubscribe <<
