'Re: Should KDED4 run all the time?'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Should KDED4 run all the time?
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2014-07-01 23:11:14
Message-ID: 665C7593-8194-445C-BB61-00ADEAB282D6 () gmail ! com
[Download RAW message or body]

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.au@gmail.com> wrote:
> On 30/06/2014, at 11:37 PM, Sune Vuorela wrote:
> > On 2014-06-28, Ian Wadham <iandw.au@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 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 <<
[prev in list] [next in list] [prev in thread] [next in thread] 