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

[Jeremy Whiting]

Ian,

Ok with your patch applied and those debug messages added I do see
Requested klauncher to start, but I don't ever see KLauncher replied OK. I
do after a bit see "Communication error with launcher, Exiting! as before.
If I find some time today I'll dig into why this is happening, we'll see.

On Fri, Feb 6, 2015 at 3:54 AM, Ian Wadham <iandw.au at gmail.com> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150206/4eafd913/attachment.html>