[KDE/Mac] Potential blocker in kdeinit5 and klauncher5 on OS X

[Ian Wadham]

Hi Jeremy and David,

On 06/02/2015, at 2:26 AM, David Faure wrote:
> On Thursday 05 February 2015 06:23:32 Jeremy Whiting wrote:
>> Ian,
>> 
>> I've applied this patch here to kinit framework and built it. I then tried
>> launching kdeinit5.app by running
>> /Applications/KDE/kdeinit5.app/Contents/MacOS/kdeinit5 klauncher which
>> seemed to run ok and didn't complain about not being able to communicate
>> with klauncher. I then started kanagram to check if the ghns would work now
>> that klauncher is running, but it complained (kio complained I guess) about
>> not being able to start klauncher5. I think I'm not testing this correctly
>> in other words.
>> 
>> David,
>> 
>> Which applications/daemons should I be starting manually, and which should
>> be launched from code (kio or other code) via their dbus .service files or
>> whatnot? Should I run kded itself, should I run kdeinit5 klauncher to get
>> that started, or just kdeinit5 itself with no arguments? Do I need to use
>> kdeinit5 to launch anything besides klauncher ?
> 
> The usual way is: just run kdeinit5 without arguments.
> (after ensuring you have a DBus session)

Yes, klauncher5 is started by kdeinit5 by default --- but kded5 is not. Both are
started by default in kdeinit4 (in Linux at least).  In kdeinit5 you can request for
kded5 to be started by using the --kded option as an argument.

Trying to run GHNS (which runs in kded5, I think Jeremy said) is a kind
of end-to-end test.  I am only looking at getting the various processes
running on OSX by proceeding one step at a time.  Because of the
blocker, I believe "kdeinit5 --kded" will fail to start kded5 on OSX.

To detect the blocker after starting klauncher in kdeinit5 on OSX, you need
code in kinit.cpp like (N.B. "fprintf(stderr," is used for logging in kinit.cpp):

    if (launch_klauncher) {
        start_klauncher();
        fprintf(stderr, "Requested klauncher to start\n");
        handle_requests(d.launcher_pid); // Wait for klauncher to be ready
        fprintf(stderr, "KLauncher replied OK\n");
    }

If you do *not* have my patch in klauncher.cpp, I think you will never see
"KLauncher replied OK" on OSX, because KLauncher will not have a socket
on which to reply, so kdeinit5 will be blocked and will then never get to the
bit of code where it starts kded5, even if you run "kdeinit5 --kded".

If my patch *is* in klauncher.cpp, it is intended that there will be enough
socket code for KLauncher to get a reply back to kdeinit5, but no more than
that.  All other process launches go via QProcess in klauncher5 on OSX, as
far as I can see.  Ditto in Windows.

@David: I realised that klauncher5 would not be sending *requests* to
kdeinit5 on OSX, but thanks for the tip about Windows.  Its version of kinit
code (kinit_win.cpp) is quite different and uses no socket apparently.

Another blocker I found in kdeinit4 last year was when waiting to hear back
from kded4.  Kded4 never replied in OSX (I tested that), and perhaps not in
Linux (I could not tell for sure when reading the kded code).

But I see, in the latest code, that kdeinit5 does not wait for kded5 any more,
so no blocker there.

So, Jeremy, if you put my patch in klauncher.cpp, "kdeinit5 --kded" should start
both klauncher5 and kded5 on Apple OS X.  If you do not want klauncher5 as
well, try "kdeinit5 --kded --no-klauncher".  It is also a good idea to do a "before
patch" test, with a log message to ensure that start-klauncher() *is* being called
and there *is* a blockage in kdeinit5 on OSX.

Please let us know your results.

Cheers, Ian W.